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ABSTRACT 


Synchronization code is necessary to control shared access of an abstract data object in 
a parallel-processing environment. This thesis explores an approach in which a 
synchronization property can be specified in a high-level nonprocedural language, and an 
implementation for the specified property can be synthesized algorithmically. A problem 
specification language is introduced in which synchronization properties can be expressed in 
a structured but natural manner. A method is then presented for synthesizing an 
implementation. An intermediate form, called a solution specification, is first derived, 
representing an abstract solution to the problem. The derivation of the solution 
Specification accomplishes the transformation of the specification from nonprocedural to 
procedural form. The solution specification can be translated directly into a source 
language synchronization mechanism, such as a monitor. 


Specifications for common synchronization properties, such as the readers-writers and 
bounded buffer problems, are expressed in the problem specification language. 
Corresponding implementations are then synthesized for these problems. In addition, the 

derived solution specification can be used in analyzing the soundness of the original 
' problem specification with respect to criteria such as freedom from deadlock and starvation. 
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“Chapter 1 


‘Introduction and Background i 
1.1- Goals of the thesis 


. ae: thesis is concerned with the problem of synchronizing a accesses By concurrently 
executing Broce ona shared data a object Overall the thesis has two ua goals. One is 
to design a high- -level cue in which syncheeniralion:p stoperiier can be specified i ina 


nonprocedural form. The other is to devise a method for translating such sg hcuahe 


into actual source language:code that implements the specified properties. 


The reliability of computer software mas received a great deal of attention in recent 


years. rs reasons are both economic and intellectual Rapid advances in hardware 


technology have dramatcly decreased the cost of ‘hardware relative to Scitane, as well as 


ae 


i the range: of one computer applications for Which new software is is required 


Ws 


Asa result, the cost of producing and ee corinne has become more than ever a 


ma jor concern. Since cen and debugging incorrect programs c consume a large share of 
total software costs, methods for IMPROVE. the = reliability of software are increasingly 
important from an economic viewpoint. At the same time, the intellectual difficulty “ad 


producing high quality software has become more generally appreciated. The study of how 


to produce complex yet reliable software systems represents. fertile area for research. 


-}- 


One productive approach in this ayea hasdeen the study of language support to 
enhance software reliability. The range of current. work, in the_area is quite broad, as 
illustrated by [LDRS77]. A sarefaulas aspect of ini Rae ita has received wide 
attention has been the idea of abstract data types (Lis#4#]: shaguage support far abstract 
data types gives Bice rarnmness a eae al sph oepaghints toe data abstractions oe to the 


capability provided by procedures for functional abstractions. Folowing a ‘methodology 


gene: dats abstractions has been found to be a significant aid in + producing, reliable 
software. — | . 


A number of languages have. esa doves and in:-many..cases: implemented, that 
include mechanisms supporting the concen: of abstract data types (eg. pier [Sha77}, 
(Ges77}). Because of a lack of facilities in these languages for creation . of multiple 
concurrent processes and interprocess communication, their range of programs, until ase 
has been restricted to single proces computations piowever, it is s obvious that many of the 
kinds of applications for which the reliability provided by data abstractions are needed, 
such as operating ayRen, require such ‘ruskiprocessing capabilites. In introducing facilities 
for concurrency and interprocess communication into these languages it is necessary to do 
so in a manner that maintains the philosophy and methodology that such languages 


support. 


This thesis explores a particular approach:to a: key problem.in this-area. The issue is 
the proper synchronization mechanism for a language that supports an abstract data type 
mechanism. Specifically, it is assumed that objects of abstract types in the language are 


shared among different processes and can be accessed concurrently. This means that some 
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sort of synchronization mechanism is required te regulate these concurrent accesses. 
Synchronization may be required both: to maintain. the internal. consistency of the objects 


- and to implement higher-level ee decisions. 


Tne approach taken net involves _speaiyng synchronization properties in a 


1 


high-level sanpricdural tguage: hid obtaining automaticaly an implementation for the 

specified property. Synchronizing concurrent accesses to data. can be a complex, error- prone 
task. Since the: reliability of programs that accessishared data depends:upon the correctness 
of the synchronization, it is highty: desirable that: the synchronization itself be implemented 
as reliably as possible. If a specification language can be developed that is powerful enough 
to: express. synchronization: properties of ‘interest, and:for which implementations: canbe 
synthesized automaticaily without too:much effort, then:it can: be:incorporated into a source 


URES that a data piccuusis eek able in ne source baa a can apecity 


seo PAyiggire 


synchronization properties nonproceduraly ata high eye and ne compiler can produce 
the actual code using the synthesis sigrithm. This would be a very attractive alternative to 
the range of synchronization qiechaninil currently Melliges some of which are ¢ surveyed i in 


the next section. 
1.2. Synchronization mechanisms .. 


"Whenever concurrent processes share access $ to ¢ common resources, it is cman: that 


= yg age me 
fa TELS 


accesses by different processes be coordinated. The purpose of ‘ynchronivation code, in the 
broadest sense, is to bring about this coordination. One kind of coordination involves 


limiting the combinations of simultaneous accesses allowed on a resource. That is, it is 
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sometimes mecessary for certain accesses to exciude others from taking place at the same 
time. This may be because the resource can inherently support-only a limited number of 
concurrent accesses. For instance, a physical: device such-as.a card reader must be devoted 
toa Single prostes at a time. Alseenyey: the nature of me accesses may be such that 


certain kinds of accesses performed concurrent would lead | to inconsistent results, such as 


the case of two simultaneous update toa database 


When certain accesses-are prevented from occurring immediately, provision must be 
made for these deferred accesses eventually. to take place. This is another aspect of 
coordination that must be handled by the synchronization code. Not. only. must a 
mechanism exist for deferring accesses. Decisions must be. made. as to when. deferred 


accesses should occur, and these accesses must be activated in. some way. 


In wong on synchronization problems, it has been found tat writing 
Seon code is a ae difficul task, more ¢diffcuk in coe than writing 
sequential programs. This difficulty arises from the non-intuitive nature of many problems 
that arise in synchronization, sind the caribifiatorlal scoblem: associated with different 
possible sets of concurrent accesses on a resource. Therefore, several aecorstiene of 
synchronization mechanisms have evolved,° reacting: to the: increasing. complexity . of 
concurrent programming applications, and to the resulting need for better, more 


well-structured synchronization mechanisms. 
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Originally, concurrent . processes communicated. through: common. shared storage. 
Access to this. common storage was usally contrptied:by."“ecks", which were. set. prior to 
accesses. and reset afterwards. Setting a lock was accomplished: by means of an indivisible 
“test and set” instruction, usually implemented .in: hardware: * This: mechanism: was quite 
unstructured, and certainly did net-provide: great-confidence in: its reliability. In addition, 
locking protocols:involved: "busy waiting”, so.that-a. process prevented from performing an 
access because of an already set lock was forced to perform essentially: useless computation 
while waiting for the lock to be reset. With the advent of multiprocess time-sharing 


systems, this became unacceptable. 


An important step forward was the development of the semaphore:mechanism [Dij68), 
on which two. operations are possible. Operation: P-aecomplishes a “test.and decrement” 
instruction, similar to setting a lock. However, the result of an unsutcessful-"test” is to: block 
the given process and place it ona queue associated with the semaphore. This eliminates 
the need for busy waiting. Operation V increments the semaphore and dequeues a process 
from the associated queue. With processes communicating via ‘semaphores ahd using just 
these two. operations, nearly* all common synchronization problems can be solved. In 
addition to solving the busy waiting problem, semaphores, unlike locks, cari be required to 
be fair. This means that service is granted in such a way that:a givety process is not kept 


waiting indefinitely while an-arbitrary number of other processes proceed. 
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A complete generation of alternative mechanisms then appeared, all of them in some 
say variations on the semaphore concept. The propesed alternatives were designed to 
improve somewhat on the power of the semaphore mechanism. A. difficulty common to 
semaphores and these alternative mechanisms: became apparent, however. They are at too 
low. a level, comparable to goto statements in the area of control structures, While 
sufficiently powerful — to. . solve synchronisation ‘problems, they do not provide the 
programmer with enough structure to make these solutions easy to construct and reliable in 


operation. 


Recent emphasis on “structured programming” [Dij72a] and language constructs 
suitable for producing reliable software has resulted in a.new generation of synchronization 
mechanisms. Many of these new constructs attempt to internalize well-structured disciplines 
developed for the use of semaphore-style mechanisms, in much the same way that the waile 
Statement internalizes a structured style of writing loops originally developed using goto 
Statements. Among the noteworthy mechanisms in this group are conditional critical regions 
(Bri72] and monitors [Hoa74], both of which embody the idea of accessing shared. data only 
in indivisible segments of code. Both also seek to relate the scheduling mechanism for 
, deterred accesses directly to properties of the shared data as another step frainarar next 
Structure. More recent alternatives have attempted to improve further on these mechanisms. 
For example, serializers [Hew77] have drawn on experience with the use of monitors to 


build even more structure into the mechanism, and thereby correct certain perceived 


. deficiencies in the monitor construct. 
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It is certainly easier to program solutions to non-trivial synchronization problems 
using these well-structured mechanisms than with semaphores or the like. However, 
synchronization remains an area of great complexity, and thus unreliability, in any large 
concurrent system such as an operating system or database management system. There is 
still a large conceptual gap between one’s understanding of a synchronization problem and 
the code one must write to solve it. This has motivated recent work whose goal is to allow 
the expression of synchronization problems in a more natural form, and in some cases, to 
obtain automatically an implementation for the specified property. Some of this work, and 


its relationship with this thesis, is discussed in the next section. 
1.3 Specifications and synthesis 


Originally, synchronization problems were expressed simply in natural language. The 
informality of such descriptions was a contributing factor to the unreliability of the 
“solutions” proposed, as well as a source of controversy over just what a problem description 
“really” meant. After the widespread acceptance of semaphores, many problems were 
expressed via a representative program using semaphores. The circularity inherent in such 
a description is obvious, since the cautions to the synchronization problems also used code 
involving Sanab teres and the distinction between “problem” and “solution” beanie 
negligible. More importantly, the expression of a synchronization problem at the level of 
actual code, while bridging the gap between specification and program, left the same gap 
between people's intuitive understanding and the specification. The “correctness” of 


specifications remained problematic. 
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A number of informal. arguments about-the: correctness:.-of; an algorithm or the 
meaning of a mechanism have relied onthe notion.of “state” to. reason indirectly about the 
effect of synchronization code (eg. [Hab72], {Bri72}, LOwit6).. This.approach was used by 
Hoare in constructing. formal..proof rules, for ,meniters in {Hea74}.. However, such- an 
approach does not really formalize the meaning...of- synchronization code and 
syichieiationuiciblens themselves, but only ia their relation. to a. program:or. system as a 
whole. Issues of medularity make it desirable te-formadly specify: synchronization ‘behavior 


in isolation from the procedures being synchronized.. 


Recent efforts to create structures through which to spress syachronization problems 
include [Rob75], [Owi76] and [Gri76] [Gri?6] contains in addition a system for synthesizing 
solutions from the specification language automatically. However, in all these cases what 
can be expressed is not a synchronization problem ‘cane but rate the abstract solution to 
the problem. ‘This is an improvement over a “specification” in the form of a concrete 
program using semaphores, but it still does not allow the specification of a synchronization 
problem independent of its solution. In order to es it is facceiry to have a 
ii eae language for describing synchronization behavior that is independent of 


notions of how to implement that behavior. 


Path expressions [Cam74] are a nonprocedural language for expressing 
- ‘synchronization. problems. In addition, implementations can be derived directly from path 
expression specifications. Path expressions represent the, most nearly comparable work to 
this thesis, both in overall goals na in basic approach. A discussion and. evaluation of 


path expressions will be deferred until the approach of the thesis has been fully presented. 
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A comparison of this approach with that of path expressions is presented in Section 8.4. 


‘[Gre75] introduces a theory and notation for describing system behavior, including 
synchronization behavior. This theory involves the notion of events, over which a time 
ordering relation is defined. The notation introduced in [Gre75] is very general, in keeping 
with the abstract level at which events are discussed. The specification language used in 


this thesis represents one approach toward refining and structuring that notation. 
1.4 Overview of the thesis 


The view of synchronization taken in this thesis is illustrated in Figure 1.1, which 
illustrates the sequence of events involved in accessing a synchronized shared resource. 
This view shares with a number of other recent approaches the importance of 
encapsulation. The unsynchronized resource to be shared and the synchronization 
mechanism for that resource are encapsulated into a single “synchronized resource” module. 
The details of the coordination between the two are hidden from the outside world, which 


can only access the resource through this higher-level module. 


The distinguishing features of the approach here concern the structure imposed on 
synchronized accesses of the resource. As indicated in the figure, every access involves a 
certain fixed sequence of events. The process wishing to make an access first communicates 
this desire to the synchronization mechanism, and this is denoted as the “request” for the 
access. When the synchronization mechanism permits the initiation of the access on the 
actual resource, the “enter” event occurs. The termination of the access is communicated to 


the synchronization mechanism in the "exit" event. 
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Figure 1.1. Accessing a synchronized resource 


synchronized resource module 


unsynchronized synchronization 
resource mechanism 


<—request 


enter —— 
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The specification language of this thesis is designed to describe properties concerning 
the time order of these abstract events. Chapter 2 presents this language, both its syntax 
and semantics, and includes a number of examples of its use. The synthesis of an 
implementation for the specified property is described in Chapters 3 through 6. Chapter 3 
describes the abstract solution specification structure, in which events are implemented by 
abstract notions called “gates”. The algorithm .for deriving an equivalent solution 
specification from a problem specification is presented in Chapter 4. Chapter 5 explains the 
implementation of a solution specification in actual code, where the abstract gates are 
replaced by procedures of a monitor. Several examples of complete synthesis for well-known 
synchronization problems are presented in Chapter 6. The detection of certain types of 
erroneous specifications, those that permit deadlock and starvation, is discussed in chapter 7. 


A summary and evaluation of the thesis is contained in Chapter 8. 


This empty page was substituted for a 
blank page in the original document. 
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Chapter 2 


The Problem Spedification: Language 
2.1 Introduction 


The focus of this chapter is on the language used for: expressing synchronization . 
constraints on accesses to an abstract. data object...Before the. language itself can. be 
presented, however, it is necessary to “set. the. scene” in-terms of.exactly what kind of data 
objects.are being treated, what the nature of accesses to these. objects is, and what kind. of 
synchronization of these accesses is possible. These issues are discussed. in. the first- two 
sections of this chapter. Then an overview of the language is presented, including some 
motivation. This overview should make it easier to understand the following two sections, 
| which formally define the syntax and semantics of the language, respectively. The chapter 
concludes with some examples of using the language to express common synchronization 


problems. 
2.2 Data abstractions and synchronization 


The data objects with which this thesis is concerned.are of the sort that are handled 
in a language supporting the notion of .abstract.-data types, such as CLU([Lis77]) or 
Simula((Dah72)). A data object in one of these languages. is strongly.typed, which is to say 
that its data type is an integral part of the object, and represents.a severe satvicaicntien how 
the object can be used. In particylar, there is associated with the abstract data type a set of 


_basic procedures, or operations, An object.of the type can only be accessed through. these 
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operations, or through higher-level procedures-that- themselves make use of the operations. 
Furthermore, it is only these operations: that are allowed to: manipulate the lower-level 


representation of the abstract object. 


In general, an abstract object can be either mutable or immutable. An object is 
mutable if it has state, so that its behavior can change over tie. Immutable objetts do not 
have state, and once they are created they are fixed for ail time. Thus they are risk useful 
for communication between parallet processés, arid corisequently are not of great interest 

with regard to synchronization. The data objects treated throughout this thesis: ate 
generally mutable. 

An operation of a data type whose objects are mutable can have the: function of 
creating an object of the type with some. (possibly Parameterized) pital diate, of accessing 
the obs S$ state without modifying it, or cot accessing | and ss Beak sg State. Assignment 
of the object to a variable is not considered to be an ppstailon on the object, but instead 
constitutes a (temporary) binding of the variable to the object. See [Sch78] for a more 


detailed discussion of the semantics of a language such as CLU. © 


Synchronization is considered here to impose a cofistraint ‘on the otherwise 
unconstrained time ordering of accesses to an individual data object. By this model, the 
ordering among accesses to different objects is completely uritonstrained, except for the 
_ Mofmal sequencing order within each individual - process. This means that if 
synchronization is required among actesses to several objects, then these objects must be 


collected together into a single composite object, with the synchronization applying to this 
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new higher-level object. It is important to keep in mind that it is the accesses on an object 
itself, not on any particular variable that happens to be bound to that object, that are of 
interest. Concurrent processes that share access to a data object presumably employ 
different variables for the purpose of referring to it, but it is over the total set of all these 


accesses that synchronization is required. 


This thesis will not be concerned at all with the exact mechanism by which there come 
to be concurrent processes, or with how such processes gain joint access to a shared data 
object. It is not important whether the processes represent saticiafrenk users of a 
time-sharing system, or are created from one process by some sort of fork-join mechanism in 
the language. Nor does it matter if the shared object resides in some form of central library 
to which all processes have access, or if a reference to the object must be explicitly passed to 
each one. The issue of synchronizing accesses to an object by concurrent processes is 
independent of such concerns, and the work here applies regardless of how these issues are 
handled. The important point is that there are processes executing in parallel that 
eongurtently access the shared object. Consequently constraints must be put on the time 


ordering of accesses to the data object, and this is the purpose of the synchronization. 


A basic assumption in the approach of the thesis is that the units upon which 
synchronization should be performed are the basic operations of the abstract data type. It is 
felt that the type’s operations are the right level at which to impose synchronization 
constraints. Only these operations are allowed to access and manipulate the more concrete 
data representation of the abstract object, and so it is here that decisions by the implementer 


of the abstraction as to what pattern of accesses is necessary to maintain internal consistency 
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make sense. The ‘centralization of these pperations ina type module (such as a CLU 
cluster) permits a single expression of constraints:to cover -all accesses of the object. Since 
. the language ensures that all accesses to the object are ‘made through the basic type 
operations, the discipline required: for synchronization “can be enforced eniversally, which 
would not be true necessarily if higher-level procedures were chosen for ‘synchronizing. On 
the other hand, to the user of an n abstraction these onlay are basic and the details of 
their implementation are ankaawh (and in aes can be ¢ changed without his/her knowledge). 
Synchronization constraints at any lower level, i.e. involving code internal to these 
operations, therefore would not be meaning uct to the user. It is emacly at the level of the 
basic operations of a data abstraction that the two 0 viewpoints of the implementer and of the 
user can and should be resolved in a smooth interface. This is true for the synchronization 


component of the interface just as much as for the data component. 


A very strict division is assumed between the synchronization and data accessing 
functions involved in accessing a shared data object. This is Gasda on the philosophy that 
the task of synchronization belongs in a separate language construct, whose sole function is 
synchronization. The operations of the abstract ‘data type, on the other hand, should be 
completely unconcerned with _ this aes ERT and written assuming that 
Synchronization exists that is sufficient to Rrerents any conflicts between concurrent 
' Operation activations. Synchronization is taken to be uniform across all ee of the same 
type, reflecting the belief that a type consists not only of data accessing Operations but the 
synchronization on them as well. That is, all objects of a given type are synchronized in the 


same way. This means that the same (sequential) implementation of a data type and its 
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operations can be used with different synchronization constraints, perhaps embodying 
alternative scheduling policies or maintaining different levels of consistency, to create 


different data types. 


2.3 The guardian model of synchronization 


The model of synchronization that I use assumes there to be an abstract protection 
mechanism that conceptually surrounds each abstract data object on which accesses must be 
synchronized. (Recall the picture given in Figure 11) This mechanism ensures that the 
encapsulated synchronization mechanism, which I call the guardian of the data abstraction, 
monitors all donamunicanen with the object, in a similar manner to the "secretary" concept 
proposed in [Dij72b]. Through this monitoring, the guardian is able to maintain the 
synchronization state of the resource, an abstract representation of the history of accesses to 
the object. (This is to be contrasted with the "data state” of the abstract object, which ‘2 the 
state explicitly manipulated by the operations accessing the object.) The guardian uses the 
synchronization state information to temporarily block any process attempting an access that 
the guardian deems to be unsafe given its current state. The blocked process is allowed to 
proceed when the synchronization state has changed in such a way that the access can Safely 


occur. 


Accessing an abstract data object consists of invoking a procedure implementing one 
of the operations of the type to which the object belongs. A given procedure activation 
generates three distinct events that the guardian includes in the synchronization history of 


the abstract object. The first event occurs when the guardian first receives notice of the 
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invocation of the given procedure by the User process. Eterm this the request event.for the 
given procedure activation, :.A request event can-be likened to:the act of “taking a number” 
in a crowded bakery, and represents the very first externally visible occurrence: associated 
with the particular procedure activation. 

The next event occurs when the pos acuaty asa access to the object by 


yet 


beginning « execution of the invoked procedure. I call this ns enter event for the activation. 


i 


It is this event that often must be c delayed by the guardian u until it can safely occur. Once i it 


has Secitred: the Process way be desiimned to be erecuting the body of the + procedure. ‘No 


a ssuiigiiondc can be made as to the relative execution ends of different a activations. 


When the process has completed execution ef.the procedure;:it indicates this fact ta the 
' guardian and exits from the resource. This is the-exit event, the last-event involved in the 
activation. F requently it is the exit event for one .activation that triggers a delayed enter 


event for some other activation. Piss 334 


This model of synchronization, of course, was not conceived in a vacuum. It is the 
result of a careful avy of the kinds of of synchronization pre properties that appest in the 
literature, which presumably reflect the nature of real-world concerns. Procedure entry and 
exit are natural concepts to use, since the basis of many synchronization problems is 
specifying which combinations of procedure activations .can.be- allowed to execute 
concurrently. Clearly the solution @f such problems requires that a record be kept of which 
procedure activations are currently executing, that is.to spy, which activations have entered 


but not exited. Another large class of synchronization; properties, constituting what are 
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usually regarded as “scheduling” preperties, invelve decisions as:to ‘which of:a collection of 
processes each waiting to execute some procedure is allowed to proceed first. In order to 
- deal with such properties, it is important te.keep track of what activations have been 
requested, hence the need for request. events. My investigation of synchronization problems 
has failed to discover any other distinguished events associated. with operation activations 
that are as fundamental as these three. Since this model “per area for Sapturing : 
tynchicaization properties . of interest, ‘hae. seems to be no need for using a more 
complicated one. The ‘examples at the end of this chapter, siriteent in in the problem 


specification language that is based. on the guardian model, ip ey to its generality. 


The guardian model assumes that the set of all: events concerning a particular data 
object is totally ordered. That is to say, while many- procedure activations can be executing 
concurrently, only one request, enter, or exit event associated with a given object can occur 
at a time. his total Serine, Property is si Sal to the fact that he. “arrival ordering” 
for any particular actor in [Hew73] is total, and relies ukimately on some sort of “arbiter” 


mechanism for each data wobec 
2.4 Overview of the language 


The purpose of the problem specification is to express, in a clear and concise manner, 
an imposed constraint on the temporal order of accesses to abstract data objects of a 
particular type. To facilitate this goal, the language for expressing the specification has 
been designed to be as general as possible, subject to the requirement that it be compatible 


with the guardian synchronization model. That is, the guardian model paradigm of 
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_ Fequest - enter - procedure body execution - exit: forms the: basis of the language, but 
beyond this, the complete. freedom: of ‘first-order predicate: calculus: with ‘equality and 
ordering among integers is available. Because of the: power .of predicate calculus, any 
_ Meaningful synchronization constraint shag operates: on the level of the time ordering of 


individual events can -be expressed. ; 


This Sie in fact, permits spectations to be written that must ‘be judged er errorieous. 
Such an invalid specification may, for instance, pace a constraint on the circumstances 
. under which a particular request event can occur, which would be incompatible with the 
guardian model. For certain kinds of erroneous b specifiations, the invalidity. can be 
discovered in attempting to apply. the synthesis algorithm presented im Chapter 4. The 
detection. of other undesirable properties, namely deadlock: and starvation, can take: place 
after the synthesis is performed, and this is the subject of Chaptes 7, 

A specification is written for an abstract data type, and is intended to apply 
independently to every object of that ype “The s specification expresses a constraint on the 
ordering of accesses to the object, and represents the only such constraint. This means that 
any ordering of events that is consistent with. the specification is valid, and in particular 
that procedure activations are allowed to execute in parallel unless constrained otherwise by 


the specification. 
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The distinctive elements of the specification language concern events and their 
ordering in time. Time ordering between events is embodied in the “temporally precedes” 
relation, which is denoted by the infix symbol “ => ", and which is adapted from [Gre75]. 
This relation is a strict partial order, transitive and anti-symmetric. The parallelism in a 
compufation prevents the ordering from being total, but the set of events associated with 
accesses of a particular abstract data object is assumed to be totally ordered, as explained 


previously. 


Each activation of a basic operation on a given abstract data object is identified by 
the name of the procedure being called and the activation number. Procedure activations 
are numbered uniquely for each data object according to the (total) ordering of the request 
events associated with the activations. The convention used here is that activation numbers 
are written as subscripts to the procedure name. The sixth activation of procedure p (i.e. 


the activation associated with the sixth request for p) therefore is denoted "pg". 


A particular event associated with an access is denoted by adjoining to the procedure 
activation formula the event type (request, enter, or exit) as a superscript. For example, the 
exit event associated with procedure activation pg is denoted “pg™".” Every event belongs 


to an event class, eg. the p*™*" event class consists of the events p,°"'", po’, etc. 


Activation numbers appearing in a specification can be any integer expressions, with 
important special cases being integer constants and variables. Constant activation numbers 
can be used to refer to a specific event of a particular class, such as the first one in a 


history. Wariable activation numbers are more generally useful, though, since they allow 
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reference to a general member of an event class. In the absence of explicit quantification, 
activation. number ‘variables are assumed’ to be universally quantified. This ts a useful 
convention, permitting a specification that refers to event i. for example, to represent a 
constraint on the enter event of any activation of procedure p. The use of expressions as 


activation numbers allows a specification to deal with related activations, such as p,; and 


Pist- 


It is ‘soesibte but not necessary, to include the arguments to procedure aiiivations If 
not included, they are assumed to be unimportant, and the specification applies to any 
‘activation of the particular procedure. Including the arguments-to an activation can be 
useful for constraining these arguments im-some way; and thereby limiting the applicability 
of the specification to those activations whose arguments meet the dcriastink The identifier 
of the process making the procedure activation can -be used “as One of the arguments of the 
procedure, so that if the identity of the particular’ process is important, it can be included in 


. this way. 


The actual abstract data object on which the synchronization is being performed is not 
included as an explicit argument to any of the: procedures operating on it. In this respect, 
this kind of specification resembles the "state machine” specifications used by Parnas for 
_ Specifying the behavior of the operations of an abstract data type (see [Par72], eg.). It can 
be assumed that operations are called by a mechanism such as the “dot” notation of Simula 
([Dah72]), by which operation p on abstract ab ie x with srcuents a aiid b is called via 
the statement "x.p(a,b)”. A spetincaton referring to siaration 6 might list arguments a and 


b explicitly, but no reference would be made to object x. The specification would implicitly 
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As an acaiaple of a specification expressed in this language, consider the following 

expression, which also appears as example | in Section 2.7: 
(pr nes an) 5 (p,*" = qn) 

This specification refers to two procedure activations, p; (the i-th activation of procedure p) 
and qj (the j-th activation of procedure q). Variables i and j appear free in the expression 
and therefore are universally quantified, and since no constraints are placed on the 
arguments to the procedure activations, the specification in fact applies to any activations of 
procedures p and q.. The specification states that if the enter event for qj is preceded by the 
enter event for p,, then it is also preceded by the exit event for the same activation of p. 
That is, a currently executing activation of procedure p (on a given object) excludes a 
Subsequent activation of procedure q (on the same object) until the activation of p is 
edrapleved: Notice, though, that concurrent activations of p and q are allowed, as long as 


the activation of q begins (i.e. enters) first. 
2.5 Syntax of the language 


This section presents the syntactic rules for well-formed specifications. The notions 
identifier and. arithmetic expression are assumed to be basic. An arithmetic expression is a 
series of one or more identifiers and/or integer constants separated by the usual arithmetic 
operations. The other notions are defined in terms of these two and each other. In each 


rule the concept being defined appears in italics: 
(1) A procedure name is an identifier. 


(2) A term is an arithmetic expression. 
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(3) An activation number is a term. 
(4) An activation name is a procedure name, subscripted with an activation 
‘number. 
(5) An activation expression is either an activation Name, or, an activation name 
followed by a left parenthesis, followed by one or more terms separated by 
commas, followed by a right parenthesis. 
(6) An event type is one of the elements of the set: {request , enter, exit}. 
(7) An event expression is an activation expression superscripted. with an event 
type. | ee | | 
(8) An ordering clause is an event expression followed by the symbol => 
followed. by another event expression, a 
(9) An arithmetic relation is one of the elements of:the set . 
Rees >.$,2 

(10) Ani argument constraint is a term followed by an arithmetic relation followed 
by another term. "7 
(11) A clause is either an ordering clause or an argument constraint. 
(12) A specification is defined by: | 

(a) A clause is a specification. 

(b) If S is a specification, then (— S) is'a specification. 

(c) If S; and So are specifications and op is an element of the set 

| Op =fA,V.2,4, 5 | 
then (S; op So) is a specification. 
(d) If S is a specification and i is-an identifier, then V i (S) and 3 i (S) are 


specifications. 


The “argument constraints” defined in rule (10) may refer to the activation pumbers 
and/or to the arguments to the activations (which are the “terms” in rule (5)). They may not 
refer to the actual abstract data object in question: however, since it oo not appear as an 


explicit argument to any of the procedures. In fact, a. Gawd rule is $ that the arguments of 
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procedure activations to which predicates may refer are limited to immutable objects, such 
as integers. The interpretation of a relation on a mutable object would depend upon the 
point in time at which the rélatiob is taken to apply, and might itself require 
synchronization on the given object. Rather than becoming involved in questions such as 
these, I choose to limit the predicates on activation arguments to immutable objects. This 


restriction does not appear to be severe. 
2.6 Semantics of the language 


The definition of the language whose syntax has been formally defined in the 
previous section can now be completed by means of a formal definition of its semantics. 
The purpose of the language is to express synchronization properties, that is, to constrain 
the order of accesses on an abstract data object. The semantics of the language therefore 
can be defined by specifying the collection of access histories that are valid with respect to 
any given specification in the language. This is accomplished by defining a predicate 
Valid(h, s), which decides for any history h and specification s whether h is a valid history 
with respect to the constraint expressed in s. First, however, it is necessary to define the 


concept of a history, and to restrict the concept to histories that are physically possible. 


The first step in this process is to define the notion of “event”. An event is a 5-tuple 


<p, t, x, n, a>, such that: 
(1) p € P, the set of basic operations of all types. 
(2) t € ET, the set of event types, where ET = {request, enter, exit}. 
(*) x € Ob, the set of all data objects in the system, and p is a basic operation for 


the type of x. x is the data object on which the access is taking place. 
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-(4)n € N°, the set of positive integers. n répresents'the activation number. 

(5) a is a vector faj,..... ap). whereeach element a, ¢ Ob.: a is the vector. of 
arguments to p. . eee . 

The types of the objects aj, .. , a,, must match the types of the parameters to 
A partially ordered set of events forms a computation history, provided that the partial 
order fulfills the condition that each object history is totally ordered. An object history for 
data object z is a subset of a computation history, consisting of all events <p. t, x, n, a> in 
' the computation history such that x =z All events in an object history are on the same 
data object, so that the third component x of each event tuple can be eliminated, and each 
element of an object history is simply a 4-tuple <p, t, n, a>. Throughout the rest of this — 
section, we will be concerned exclusively with object histories, though the simple term 


. “history” will be used. 


Since the events in a history are totally ordered, the history may be considered to be a. 
sequence of events. A sequence over a domain D can be defined as either the empty 
sequence [ J, or else the result of adding an elément d € D to the end of a sequence s, which 


is given by the expression "add(s, d)”. 


Not all histories are actually possible. In order to define what class of histories are 
possible, some further definitions are required. An event class for a data type dt is a pair 
<p, t>, where p € P and t € ET, and p : a basic operation oh data ie dt. The set of 
occurrences of an event class <p, t> in a history h is.a.set.of pairs of the form <n, a>, where 


n is an activation number and a is a vector of arguments, such that an event of the form 
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<p. t, n, a> occurs in history h. Formally, this is given by Occurrences(h, <p, t>), where: 
Occurrences({ ], <p, t>) = {} 
Occurrences(add(h, <py, ty, n, a>), <p, t>) = 
if (p = pj At = t)) then Occurrences(h, <p, t>) U {<n, a>} 
else Occurrences(h, <p, t>) 

With the aid of these definitions, we can now define when an history is possible. The 
predicate Possible requires a request event to precede the corresponding enter event, which 
in turn must precede the corresponding exit event. Also the ordering of request events for 
a given procedure must determine the numbering of invocations. 


Possible([ ]) = TRUE 
Possible(add(h, <p, t,n, a>)) = 
Possible(h) A 
((t = request A Occurrences(h, <p, request>) = {<i, aj>|l<i< n}) v 
(t=senter A <n,are Occurrences(h, <p, request>)) Vv 
(t= exit A <n, a> € Occurrences(h, <p, enter>))) 

A few more definitions are required before the validity of a possible history with 
respect to a specification s can be defined. An event expression is a 4-tuple <p, t, exp, V>, 
where p € P, t € ET, exp is an arithmetic expression, and v is a vector of arithmetic 
expressions, possibly empty. (The concept of arithmetic expression can be defined formally 
in the obvious manner.) Let the set of arithmetic relations Rel = {=, #, <, >, $, 2} and the set 


of logical binary operators Op = {A, Vv, >, #}. Then the set of event expressions in a 


specification s is given by Evexp(s), which is defined in the obvious manner: 


Evexple; =2@9)= {e ,€9}. 

-Evexp(exp, rel expo) = { }, for rel € Rel 

Evexp(~ s) = Evexp(s) | 

Evexp(s; op So) « Evexpls)) u Evenetigh for op € op 
Evexp(3 x (s)) = Evexp(s) 

Evexp(V x (s)) = Evexp(s) 


An interpretation isa mapping f from expressions ie data na that preserves the 


meaning of all constants and es That is: 


(i) f maps every constant expression t to the corresponding constant objet 
eg. f(l) = 1. = ‘a 

(2) f is consistent with every operation, 
eg. f(exp, + expo) = flexp,) + flexpy)... - 

(3) f maps a vector of expressions into-the corresponding vector of objects, 


eg. ner = bEXPpp) = eer fy ae 

An event e and an event expression ee match under an interpretation f if e and ee are 
of the same event class, and. f maps the activation number peubereans and parameter vector 
; expression (unless the latter is is empty) of ee to the corresponding components of e. Eorany: 
Match(e, ee, f) is defined as: 

Match(<pj, ty, n, a>, <po, to. a5, v>, f) : 
(py = Po) A (ty = ty) A (exp) =n) A (v=[] v flv) =a). 

The validity of a history with fesped to {eecinciien s can now be defined by a 
predicate Valid. The definition of Valid recursively Reexmines: when a history 4 is valid 
with respect to a specification. For a history to be valid, the F previous nidabey consisting of 


all but the last event must first be valid. Furthermore the last event in the history must 
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Satisfy the specification for all interpretations under which the event matches some event 


expression in the specification. 


Whether or not an event added onto a valid history satisfies a specification under an 
interpretation is defined by another predicate Sat. The definition of Sat for a complicated 
specification is basically just a matter of breaking down the structure of the specification, by 
removing each logical operator and applying it to the recursive applications of the 
definition, until one reaches the level of a simple clause. Satisfaction of an argument 
constraint is determined solely by say the components of the clause are embodied by the 
given interpretation, not by the event in question: Whether an event satisfies an ordering 
clause depends upon whether the event matches one of the event expressions in the clause 
unde the interpretation. If the event matches the first event expression under the given 
interpretation, then it is necessary that no event matching the second event expression 
occurs in the previous history. If the event matches the second event expression, though, 


then some event matching the first event expression must occur in the history. 


Formally, if h is a possible history and s is a specification, then h is valid with respect 
to s if and only if Valid(h, s), where: 


Valid([ ],s) = TRUE 
Valid(add(h, e), s) = Valid(h,s) A 
V (ee, f) (ee € Evexp(s) A f is an interpretation 
A Match(e, ee, f) > Sat(h, e, s, f)) 


The predicate Sat(h, e, s, f) determines whether event e added to history h_ satisfies 
specification s under interpretation f. It is defined by the following equations, giving all 


possible cases for specification s: 
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- Satth, e, (<py, ty, Expy, ¥> => <po, to, Expy, Va), f) = 
(Match(e, <p;, ty, Expy, ¥j>,f) Do... 
(vo #0] A <flexpo), Kvo)> € Occurrences(h, <po, to>)) V 
(vo=[] A. Va (dlexpg),.a> ¢.Occurrenced(h, <pp, t>))))) 
A (Matchle, <P to, exp, Yo f) > . 
(vy, # [la <f(exp)), f(v,)> € Occurrences(h, <P> to>)) v 
(vel Fa (exp). a> € Ocetirrences(h, <p). em 
Sat(h, e, expy rel expo, f) = (flexp)) rel. flexps)),. ferred €.Rel- 
Sat(h, e, > s, f) = — Sat(h, e, 5, f) 
Sat(h, e, 5) Op So, f) = Sat(h, e, 5, f) op Satth, neta Dh 15:90 < Op 
Sat(h, e, 31 (s), f) = 3m Satth,e, simi, 
Sat(h, e, V.i(s), ) = Vm Sath, esl 
The notation s{m/i] in the last two equations represents the expression resulting from 


substituting m for all free occurrences of i in s. 
2.7 Wxamples 


This section presents a series of examples of the use of the problem specification 
language. These examples have been chosen with two criteria in mind. First, together they 
illustrate the range of features that the language offers. Second, they specify realistic and 
representative properties, covering a significant portion of the classic synchronization 


’ problems that appear in the literature. 


Example i: Exclusion 
(porter = qv") > (pj =q) ; 
This specification has been discussed previously in Section 2.4. It states that an activation 


of procedure p excludes a subsequent activation of procedure q until the activation of p is 


completed. - 


Example 2: Mutual exclusion 
it» ent it an 
(p" = qj" iw) Vv iq" = pi” } | | | 
This specification is similar to example 1, except that it is symmetric between procedures p 
and q. That is, an activation of either p or q excludes any-cofcurrerit‘activation ofthe 


other. 


Example 3: Readers-writers property 
| (write ee" => write*"'*") > (write? = write?"'*") F 
((write;"" => read, *""*") v (read, ** => write;*""*’)) 

. The so-called readers-writers property concerns two operations, “read” and “write”. It states 
that activations of "read" exclude those of “write"’ and. that an activation of “write” excludes 
all other activations. of either operation. This has been re-shaped into an instance of 
example | (an activation of “write” excludes all other activations of “write"), and an instance 
of example 2 (activations of “read” and “write” mutually exctude one another). By 
combining this specification with an instance of example 4, giving one of the operations 
priority over the other, or of example 5, requiring an éaisatpriotity first-come-first-served 
discipline, one can obtain any of the classic versions of the readers-writers problem (as 


found, for example, in [Gre75)). 


Example 4: Priority 
(porns => qv") > (poner => qin") 


This specification gives priority to activations of procedure p over those of procedure q. It 
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does this by requiring that so long as the activation of q has not yet entered, then. any 
_ activation of p that has been requested must enter first, i iat of whether the veer 


event for p came after the Set event = ie the activation of 9. “This i is an wenmple of a 


eal Besa oe use of a eaeete event. 


Example.5: FCES scheduling... og sReae feats 

(peret => git) (pner => gisnter 
This specification represents an alternative to giving either of a and of caine py 
over the other. Instead it requires a strict finer ierved  disciptne between them, by 


Stating that whichever dateaton is ‘eiuested' Ti first i is the o one to enter first. 


Example 6: LCFS scheduling... 

(pire! = prom) A (pyerrn = pyr). > (pene = pi") 
Here another alternative scheduling policy, though probably a: tess ‘likely one, is specified. 
This “last-come-first-served” property requires that. of all the requested and pending 


activations of a given operation p, the one.most recently requested: is allowed to enter. 


Example 7: Operation pairing 

(a, enter me) “a G onter = ar) 
This specification requires that whichever order o occurs between ne entry ¢ of an activation of 
"a” and one of "b’, the same order must hold for the sdieponding activations of “c” and 
“d", respectively. Illustrated is the use of the same activation number fer activations of 
different procedures, i for. procedures “a” and "c", and-; for propedures "b” and "d". The 


_ Specification could be.used:for a data type in. which operations 2 and b conflict, in the sense 


-37- 


of updating the same part of the object's state;as.do operations ¢ and d, If operations a 
and c, taken as a pair, update the state consistently, and operations b and d do likewise, 


then the constraint specified here might be necessary ta prevent an inconsistent update. 


For example, in [Esw76], an example is given for which, the operations have. the 
following meanings: 
a: X := x40; 
b: x := x12; 
c: y := y+l0; 
sy c= yx; 
If the predicate (x = y) is the criterion for consistency-of the data object, then this would be 


part of the specification required. (Other constraints.also.would be necessary.) 


Example 8: Producer-consumer (single buffer) 

. (dep,**" os rem,e"*") hk (rem,*tt => dep,1°"*") 
The “producer-consumer” problem is that producers and consumers, must alternate in 
depositing and removing messages, respectively, in a shared buffer. This means that each 


deposit, represented here by an activation of procedure ."dep’, must.‘ precede. the 


-. corresponding removal, or activation of procedure “rem”. On. the other hand,.the. removal 


must take place before the next deposit can occur. This. specification again ilustrates the 
use of the same activation number, for activations of two different procedures, as well as the 
use of an expression ("i+") as an activation number. Notice that this specification could be 
rewritten so as to make the relationships between activation numbers more explicit by 


means of predicates on the activation numbers: 
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Gi) > (ep = remy’ A {rem => dep," 
This specification is exactly equivalent to ‘the original: it makés'no difference whether such 


Gi. gos 
Vtg ec eae 


relationships are represented explicicly' or implicitly. °°" ~' " 


‘Exaniple 9: Bounded buffer acts 

(dep*** => rem") A (rem;*** as dep.) es 

| (dep;*"" => dep") A (rem, => rem") 
This example is a generalization of the previous one, in that the activation number of the 
dep*"*” event has been changed from isl to isN, for some integer N. The specification is 
for the same problem, except that the size of the buffer is now N. This meanis that up to N 
Messages can be deposited in the buffer before fitfing it, so that up to N successive “dep” 
operations can be allowed before” ore has to wait for a “rem” operation. The last two 
clauses state that the individual “dep” activations must be mutually exclusive and execute in 


first-come-first-served order, as must the individual “rem” activations. 


eeapke 10: Intervening activation 

(pet = pr) > Ak pM qe" nN ge = pe) : 
This specification represents a weaker property that is implied by the préducer-consumer 
constraint of example 8. It requires that between any two activations of procedure “p” there 
must be an activation of procedure “q”. This shows the use of an existential quantifier in a 


specification to require a particular kind of event‘to‘vecar at a given point in the history. — 


Example 11: Threshold of requests 


Vik <i) A(i<k«N) 5 (pre = p,") 
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This specification places a threshold of N request events for activations of procedure "p” 
before the first one can execute. Since this applies to any value of k, the result is that 
whenever an activation of proceddre “p” is currently executing, there must be at least N 


processes that are waiting on requests to execute "p". 


Example 12: Exclusion on a restricted class of accesses 

(p,(a)er'er = qr") > (p(ay*" => qr") 
This specification is identical to example |, except that a parameter has been given to each 
of the two procedure activations. By providing the same identifier as the argument to both 
activations, this specification conveys the information that the arguments to the two 
procedure activations are equal. Therefore the exclusion constraint expressed by this 


specification is restricted to activations with equal parameters. 


Example 13: Predicate locks 

C(a,b) A (p(ayen'’" => qi(b)""7) > (p(ay"" => qo") 
This specification again represents a restriction of the exclusion constraint of example 1. 
Here, though, the restriction is represented by a general predicates C on the parameters to 
activations p, and qj This suggests how a simple version of the concept of “predicate locks” 
might be Specified. A specification of this form can be used to state the synchronization 
constraint, as long as the predicate C for which exclusion is required is known ahead of 


time. 
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For example, suppose that the abstract data object. on: which procedures “p” and: “q” 
operate is.a hierarchically organized database. The database. consists of a collection of files, 
-each of which in turn consists of.a collection. of recgrds./; Fhe predicate G:might express the 

relation that records a and b are elements of the same file: -Therefore,.procedure “p" would 


exclude procedure “q” only when they were operating on records in the same file. 


we tes EE pitpge dee 3 


The general notion. of “predicate. lacks" was introduced: in [Esw76] The more 
complicated versions. of _ the. concept discussed: there would. .require more. complex 


Specifications. 


Example 14: Disk head scheduling 
SE We (a,c => ays me (a, = aon) we 
((aj(x2yertt => a il) > a(n DM) 0 
(a,(xayenven => a, (xi => a(xayrer).a 
(ag (XO = ay (xl) A 
> Kn) (fag, (x0)™* => ap er => ay (xs)*)) A 
((x0 < x1 < x2 A (x2. < K3..V. x3-< xl) -V 
(KO > XL > x2_ A (x2 > x3. Vv x3.> x1) | 
> (ay(x2yr'er => a (x3)") | | 
The final example is the “disk head scheduler” problem; which appears in. [Hoa74], among 
other places. The problem is to schedule disk accesses so as to minimize average waiting 
time. The way this is done is to have the disk head sweep in one direction, accessing each 
hack it encounters for which an access has been requested, until no more requested tracks 


"remain in the direction in which it is sweeping. The head then reverses direction and 
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sweeps back, again accessing requested tracks as it encounters them. The essential idea is 
that at any given point, the next track to be accessed is the one closest to the currently 


accessed track in the direction currently being swept. 


The specification for this problem concerns four activations of an access procedure "a" 
on a disk, with the parameter (x0, xl, x2, or x3) representing the number of the track being 
accessed. ‘The constraint expressed is that of the two activations (aj and a) requested 
during the time that another activation (a,) is executing, the activation allowed to execute 
first is the one accessing the track nearest to the track currently being accessed (track x1) in 
the direction currently being swept. The direction is indicated by the inequality between x0, 
the track that most recently accessed, and xl. Track x2 is accessed before track x3 either 
because it is closer to track x1 (either xl < x2 < x3 or xl > x2 > x3), or else because it is in the 


right direction and x3 is not (x3 < xl < x2 or x3 > xI > x2). 


This empty page was substituted for a 
blank page in the original document. 
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Chapter’ 3° 


The Solution Specification — 
3.1 Introduction 


There is a “vast conceptual distance: separate, “on the one hand, a problem 
specification written in the language described: in Ohipter 2, :and'on the other, the 
synchronization code that .imptements the specification.’ This is:because the specification is 
a non-procedural, -requirements-oriented . expression of what should happen with no 
indication of the means by which this behavior should be realized: ‘Determination of the 
procedural mechanism, that is how to ceaenh the Sates constraint on shect time order of 
accesses, requires a fundamental transformation | in Sacagee Once this determination has 
been made, there are still a number of details that need:to'be worked out, but the remaining 
work is basicafly that of ‘the back: end: of :a-compiler, transiating from. an. intermediate 
language into actual code (though the target code in: this case is still: in a high-level 


language, not machine language). 


1 have chosen to split the derivation process into two idle The first mee is the 
transformation from sneesdural to nonprocedural form. It can be described without 
reference to the exact details of particular scares language constructs The second stage 
construc: i actual implementation. The sateienadiats form ink which the problem 
specification is transformed by the ue stage is called the solution specification. This 
chapter presents an informal description of solution sic ae followed by a formal 


definition of their semantics. The method for transforming a problem specification into an 
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equivalent solution specification is the-subject of. Ghgpter 4. The translation of the solution 
specification into synchronization code is treated in Chapter 5. 

Section 3.2 presents the “basic” structure of the solution specification, which is sala a 
first approximation to the actual structure. The basic structure pomreeg quile simple 
and elegant, and. in. fact the solutiogs 40. many synchronigetion problems can be. expressed 
within it. Unfortunately, this. simple structure tacks ‘sufficient expressive power for certain 
_ important classes of problems. For this: reason, it it: necessary: fo augment the basic: structure 
With.additional features, which are dessibed. in: Section 33; The formal semantic definition 


of the solution specification appears. in Section 3.4... ve 
3.2 The basic solution specification structure 


The structure of the solution specification, at iof the problem. specification, is. dictated 
to some extent by-the guardian synchronization.madel...- That is, the: solution specification 
must contain features corresponding to those events:asseciated with procedure activations 
that the guardian model distinguishes. Beyond this, there #s: some choice as to how rigid a 
structure to impose on the solution specification. ‘Since the contin caammens is an 
intermediate form between the oe section an and the generate code, the degree of 
flexibility represents to some extent where it ‘ies on the ‘spectrum beeen these two 
Structures. A very general solution specification sructure, corresponding 1% the generality of 
the problem specification language, would represent a decision that the solution specification 
be relatively close to the problem speciation. “The } price pa for this generality would lie 


BORE Soa eS , 3K Hoe omen: poste 


in the difficulty of translating ich a : solution speifiation into  earget. code. 
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The alternative choice made here is for the solution specification to have a rather 
rigid structure. This means that, as indicated in the introduction to this chapter, the 
fundamental transformation takes place in deriving the solution specification from the 


problem specification. 


The basic structure of the solution specification is for each guardian to consist of a 
collection of gates through which processes accessing the abstract data object must pass. 
The use of the term “gate” is taker from [Rob75], though the concept as used in this thesis 
differs somewhat from the one introduced there. Specifically, the guardian for an object of 
abstract data type t contains a gate for each event class of t. This means that for each 


enter and p® Each event 


Operation p of the abstraction, there are gates pienent p 
associated with an object corresponds to the passage through a gate in its guardian. For a 
process to access the data object by activating procedure p, the process first must pass 


through the p’*%*" pate, then through the p*"*" gate. At this point it executes the body of 


procedure p, after which it must pass through the p*" gate. 


Each passage through a gate by a process produces a (conceptually instantaneous) 
change in the state of the guardian. Because of the total ordering on the events associated 
with an object, the gate passages for a particular guardian are totally ordered. The 
ordering of processes passing through any single gate is first-come-first-served. This means 
that unless a specification explicitly requires a particular scheduling policy for activations of 
a given operation, the default policy assumed is first-come-first-served. The order of service 
among different gates of a guardian is assumed to be fair, in the sense that processes at 


different gates have equal chances of being chosen for service. That is, a requirement in 
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the implementation. is that.a process-cannot:starve. ‘because: of fack of attention from the 


_ scheduling mechanism. 


Gates for request and exit event classes are unconditional, so that haga cannot t be 
blocked in passing through these gates. A gate for an enter event cue is ondiienal 
however. Associated with each enter gate there is:some condition on the guardian state. 
This condition must be satisfied in order for the process: making the activation to pass 
through the gate. If a process attempts to pass through an enter gate whose condition is 
-not satisfied, then the process is blocked, and must wait until the condition becomes ‘true 


before proceeding through the gate. 


Schematically, then, an activation of operation p on a data object is implemented by 
the abstract program below. Since gate passages represent events, which are totally ordered, 
the abstract code representing each gate can be considered an indivisible operation. 


p’ewes': update guardian state 


Pp 


enter. wait until entry condition is satisfied, 


then update guardian state 
execute body of operation p 


p°: update guardian state 


It would appear that to represent a given solution specification, it would be necessary to 
specify for each operation p the specific entry condition on gate p°™*’, and the particular 
updates to the guardian state accomplished in each of the three gates. In fact, the form 


chosen for the synchronization state of a data object defines a priori the nature of the 


updates within all gates. 
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The history of a data object, and of the guardian for the object, consists of the totally 
ordered sequence of events associated with all accesses of the object in the entire 
computation. The state of the object represents some abstraction from the history that is 
sufficient for predicting its future behavior. An alternative way of saying this is the 
definition in [Gre75) that a state is an abbreviation for a class of histories. The 
synchronization state of the object is the synchronization component of the state, which is 


sufficient for the prediction of its future synchronization behavior. 


The decision made here is to express the synchronization state of an object as the 
number of events that have occurred at each gate of its guardian. The notation used is 
that count(g) denotes the number of events at gate g. So count(p’®*"') is the number of 
activations of procedure p that have been requested, whether:or not those requests have 
been granted; count(p®™*) is the aoniee: of activations of p that have entered, whether or 
not they have exited; and count(p®") is the number that have exited. 

This decision has a number of ramifications. The implications for the expressive 
power of the solution specification are discussed in the next section. The decision to use 
counts forms the basis for the method of deriving a solution specification from a problem 
specification, as will be apparent in the description of the derivation algorithm in Chapter 
4. With respect to the basic structure of the solution specification, it means that in the 
schematic abstract program representing an activation of operation p, each update to the 
guardian state now can be defined to be simply incrementing the proper. count. The 


abstract program therefore becomes: 
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- prewest: increment count(pe):by fo 
p’™*, wait until entry, condition, is satisfied... 
then increment countip"™") by! 
execute body of operation p 
p: increment: countip™} by! > 
That is, the ‘update to the synchronization state “within cach aie ¢ consists simply of 


incrementing the count of events at that gate ie I. xu he quantity count) t is $ similar 10; and 


in fact can be implemented by, the “eventcount” notion introduced in [Ree77)). 


This means that the representation of a particular solution wisi can consist 
simply of the entry condition on gate pm for ‘each, operation p ‘of the abstract type. Each 
entry condition on the synchronization state must t take the form of a a predicate on the counts 
of gates. The other (non-enter) gates in the solution specification 3 are indicated implicitly by 


the appearance of quantities of the form comet) within the entry cc conditions. 


For example, consider an abstraction with one ween “op”. Suppose that the 
synchronization constraint for this abstraction: requires activations of op to be mutually 
exclusive, that is, at most one activation is allowed to be executing at a time. Then the 
solution specification for the abstraction can be expressed by stating the condition for gate 
op*"*" to be | 

Seaton) - oe 
This is a shorthand way of saying that the abstract program \ for accessing an abstract data 


object via operation op is: 
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request, 


OP 
enter, P P enter tliat) |. 
op®*™*: wait until count(op*"*’) =, count(op"™"), 


increment count(op’®®**!) by | 


then increment count(op™*) by 1° 
execute body of operation dp. . °° 2) 


op 


ex" increment count(op™") by | 

As a second example, consider an abstraction with two operations f and g. Assume 
that an activation of operation f is allowed to begin execution only if no activations of g 
have been requested and are waiting. Also, let an activation of g be able to enter only if 
exactly one activation of f is actively being executed. ‘Then the solution specification for 
this abstraction consists of the two entry conditions: 
For gate fe", count(g"t) count(g**"), 
For gate g°™*. count(f*™*") - count(f*™*) = 1 
_ In other words, the following are the abstract programs for activations of f and g: 


Abstract program for f: 
freavest. increment count(fe%") by J 
fenter. wait until countig**) « count(g*™*, 
then. increment count(f""’) by. ke 
execute body of operation f 


fe". increment count(f**) by 1 


Abstract program for g: 
_ grewes!. increment count(g'®"""). by I 
gener: wait until count(f*"*"} - coune(ft™) = 1, 
then increment count(g*”*") byt 


execute body of operation g 
& 


exit. increment count(g**) by 1 


3.3 Additional features of the solution specification 


As indicated in the introduction to this chapter, the basic structure presented thus far 
for the solution specification lacks sufficient power for expressing solutions to a wide class of 
synchronization problems. Two new features must be added to, this basic structure in order 
to achieve the required expressive power. These additional features, which are the subject 
of this section, provide the ability to save and use previous state information, and the 
ability to use properties of parameters to operation activations. The first to be discussed is 


the use of previous state information. 


In the previous section, the synchronization state was defined as some abstraction from 
the history of a data object containing sufficient information fer:the prediction of the future 
synchronization behavior of the object. Unfortunately, the counts of all event classes do not 
provide sufficient information. Sometimes it is receteary to know not only how many events 


of each class have taken place previously, but in what order certain of these events occurred. 
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There are a number of sdeeinanee to usitig integer-Valued’ counts to represent the 
synchronization state. As illustrated in the previous section, it makes the abstract state 
Heer within each gate of the hae parteultly simple. As a result, the actual 
implementation of a solution specication in terms Hore a source language synenronization 
fnechaniint, which is the subject of alae > can be both h simple pier eHticient This 
efficiency si is smportan in ensuring that the synchronization code itself does not significantly . 


affect the concurrency of the computation. lee: use of counts is Sets Important. in terms of 


the ere sveuiade in Chapter 4 for gening a sotreny speciation from a problem 


A 
Tete? Y 
a 


specification. For these reasons, it is desirable to ‘remedy th the ack of faired power in a 
way that does | not sacrifice the advantages of veins counts ite events as cog basic form of the 


* 


Guchi onan State. 


The way to accomplish this is to add to the basic solution ‘specification structure the 
ability to save the ee eee State at the time of an event: ane state of the guardian 
then includes not es the current synchronization state, but aio: each previous state that 
has been saved. Conditions on enter gates can be be expres i in terms of both the current 
ay ehnon Aen state aid any Aniorenanon saver from Baka states. AND the aRIORTOAH OH 
that is lost by abstracting from the serait sequence of events within the history to the 
counts of event classes can be regained by using the state at the time of prior events as well 
as ce current state. Basically the reason for this 1s that when it is necessary to know 
whether some particular event e; has preceded sone other event €o in the preceding 
sub-history, this information can be obtained by comparing information in the states when 


e€; and € occurred with the current state and/or each other. In Chapter 4 it is explained 
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‘how previous state information is derived to express properties for which the current state 


is insufficient. 


A notational extension is needed to represent pees state information Unless 
indicated otherwise, quantities nisin, in a condition ii cheats current ate values 
When a quant is meant to represent a ‘value i in ‘the state ‘at some Previous ¢ event the 
notation “e g” appended to the quantity is employed, where 8 isthe the name of some Gate. 
This means that the quantity refers to ‘the state saved. silt prior to the most recent event 
occurr ing at gate g. For aire the number of activations of p that t had been requested at 
the point at which the most recent exit event for Procedure q has occurred is denoted 
[count(p"*™**") @ q’*I Notice that since the state is ‘saved just before the indicated event, a 
quantity such as [count(q**") @ q®**) does not include the q*"* event actually occurring at the 


point at which the state is saved. 


As an example of a solution specification that uses sreviens'stabe information, consider 
an abstraction with two operations u and v. Suppose that nis desired not only that 
activations of operation u be poe CKCUBYG but that between any two successive 
activations of u, an enter event for operation v must occur. This can be devitased by the 
condition | 

count(u"™*) » count(y) A” [count(v*"*") u*#) < count(ve™") 


enter’ The second connie of the condition aay that count(ven") ¢ must increase 


for. gate u 
between the exit event for the most recent activation of u sae the time the next activation 


of u is allowed fo enter. The corresponding abstract program for an activation of u is: 
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request, 


u increment count(u’e?**') by 1 


enter, 


u wait until count(u®™*’) = count(u®") a 


[count(v®"*’) @ u®*"y < count(ven*’), 


then increment count(ue*’) by | 


execute body of operation u 


exit, 


: Save the guardian state, in particular the quantity count(v°"'*’), 


u 


and increment count(u®*") by | 


Each event at gate u®™*? uses the value of count(v°"*’) saved at the most recent u®*'t event 


in its entry condition. 


As before, a solution specification is represented simply by the entry conditions that 
apply to all enter gates in the guardian. The state information that must be saved is not 
listed explicitly. Instead it is indicated implicitly by the appearance of quantities of the form 


[count(ec) @ g], where ec is an event class and g is a gate, within entry conditions. 


There is another aspect of information that is lost by abstracting from the history of 
an object to simply the count of events in each event class. The history is a sequence of 
events, each of which is described not only by its event class, which is to say the Spectator 
name and event type, but also by the vector of parameters passed to the operation. All 
information concerning the values of these parameters is lost when considering only the 
counts of event classes. For instance, it may be necessary for activations of an operation to 
be mutually exclusive only if an integer parameter of each activation is non-negative. Such 


a property can be expressed in the problem specification language of Chapter 2, but not in 


a solution specification with the structure presented thus far. 


= ae owe ett 
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The solution is to “qualify” gates in the solition. specification. A gate is qualified by 
the attachment of some eg’ on the je pararheters of the ‘associated ‘procedure’ activation. 
Only if the parameters of an activation sat the predicate Sots the process making the 
"activation pass through that gate. An unqualified gate, which applies to all. activations of 
the given procedure, may be corisidered’ to te ar apa case of a qualified gate, with 


a qualifying predicate that is identically TRUE for all parameter values. 


Some new rasan is needed in order to refer " gales An unqualified gate, as before, 
is indicated simply by the event class it is in, such as the p*™*" gate. A qualified gate is 
denoted by appending the qualifying predicate to the procedure activation expression. The 
notation used is similar to that employed’ in set theory, with a vertical bar used to separate 
_ the predicate from the activation expression. Therefore, {p(v) | C(v)"™" denotes a gate in 
the p°*"* event class that is qualified by the: predicate C on ttie‘ vector of parameters’ v to 


procedure p. 


As an example, consider’ the following’ situation: Let an abstraction have one 
operation h, taking a single integer parameter x. Let all activations of h with non-negative 
parameter values be mutually exclusive. Then the solution specification contains thie 
condition 

count({h(x) | (x 2 0)}™) © count([h(x) | (x 2°0)}?") 
for gate (h(x) | (x 2 O0)F*", This means that the gates'for both the h™™" and h*** event 
classes are qualified withthe predicate (x 2 ‘0),-and that any activation of h whose 
parameter does not satisfy this predicate need net pass through these gates. That is, the 


abstract program for an activation of h with parameter x is: . 
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h'est, increment count(h’?™) by 1 
her. if x 2 O then ; | 
wait until count((h(x) | (x 2 0)P"*") = count({h(x) I(x > or), 
and then increment count({h(x) | (x 2°0)}"") by 1 
execute body of operation h with parameter x 
het. if x 2 0 then ee . 
| increment count({h(x) | (x 2 oy) byl 
Since gate h'°%**" is not qualified, all activations must pass through it, regardless of their 


parameters. 


Allowing only one qualifying pitedicare for an event dass would be overly restrictive. 
It may be necessary to maintain counts of several different subsets: of events. in an event 
class, where each subset is distinguished by a different predicate on the operation 
parameters. These subsets may het be disjoint or overlap. Also, different entry 
conditions may be required for different subsets of the total set of activations of an 
operation, and again these subsets may be disjoint.or overlap.. It is therefore necessary to 
generalize the above structure by allowing more than-one gate for each event class. Each 
gate in an: event class is distinguished by a-different, qualifying predicate, and each gate of 
an enter class may have a different entry condition as.well..When there. is more than one 
gate for an event class,-a process passes through. exactly that set of gates whose qualifying 
predicates are satisfied by the parameters of the activation, it is making. These gate 
passages are assumed to all occur in parallel. It is this simultaneous passage through a 


subset of the gates in an event class that implements the abstract notion of an event. 
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The implementation of each event class by a whole: set of: gates is a fundamental 
change in the structure of the elitin sso anaiin ‘ is Perhaps ‘best understood by 
looking at the new abstract, program for an setleation of of operation Pp with parameter vector 
Vv: 

prewest. in parallel for all gates g in event class prewest: 


if v satisfies the qualifying predicate of g, 
_ then increment count(g) by ! 


p*"'*': in parallel for all gates g in event class porter, 
if v satisfies the qualifying predicate of g, 
then wait until the entry condition of g is satisfied, 
‘and then increment count(g)'by 1 Soe 
execute body of operation p - 
p*". in parallel for all gates g in event class p*™, 
if v satisfies the qualifying predicate of g, 


then increment count(p™) by I 


Since the events in an object history are totally. ordered, each event must be an 
indivisible operation. This means that all gate passages making — event occur, at least 
‘in a conceptual sense, in parallel and: simettaneously. in :particalar, it means that a process 
‘may not pass through aff enter gate untess it-can pass through ail-of-the enter gates for the 
‘given event class whose qualifying predicates are satisfied by its parameters.: Only when all 
the entry conditions on these gates are satisfied may: the-enter event, in the form of the 


paraliel passage through’ all: these gates, take place. 
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As before, the processes that are blocked at a given enter event class are queued up in 
FIFO order. However, they need not be unblocked in this same order. Each process in the 
queue is waiting on one or more conditions, depending upon which qualifying predicates on 
gates apply to the activation. The process that proceeds first is the one closest to the front 
of the queue for which all entry conditions are satisfied. This may not be the one at the 
head of the queue, since iat process may be waiting at a different set of gates than other ~ 


processes further back in the queue. 


It is important that the distinction between qualifying predicates and conditions on 
gates be clear. A qualifying predicate can be attached to a gate of any event class, and 
represents a constraint on the parameters of the associated procedure activation. If the 
predicate is satisfied for a particular activation, then the process making the activation 
passes through the gate, while if it is not satisfied, the process bypasses the gate. A 
condition, on the other hand, applies only to an enter gate. This condition is on 
synchronization states, the current state and perhaps also one or more previous states. If the 
condition is true, then the process may pass through the gate. If it is not, then the process 


becomes blocked, and must wait in a queue for the condition to be true. 


As an example of a solution specification employing multiple gates, consider the 
abstraction discussed above with one operation h. Assume now, though, that h takes two 
integer parameters x and y. As before, activations of h for which parameter x is 
non-negative must be mutually exclusive In addition, though, we want activations *for 
which parameter y = 5 to be excluded whenever there is an activation currently executing 


for which y > x. The solution specification for this example consists of the following two 
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conditions: 
-For gate [h(x,y) | (x 2 orn’: 
count({h(x,y) | (x 2.0)7"*") « count(Lh(x,y). | x 2- Ore) 
For gate [h(x,y) [(y = 5)": 


count{lh(xy).| (y > x") = count(legxy) | (y >.x)P*) 


These conditions require two gates with entry conditions for event class h*"*’, with 
qualifying predicates (x > 0) and (y = 5). There must be ates in both the ‘penter and het 
event classes to maintain counts for. the qualifying presicates (x.2 0) and (y > x). The 


abstract program for an activation of -h with parameters x. and. y.consists of: 
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hrewest. increment count(h’’**') by | 


a in parallel, . 
if (x 2 0), wait until 
count({h(x,y) | (x 2 0)]°"*") = count({h(x,y) | (x 2 0)]°*"), 
and if (y = 5), wait until 
. count([h(x,y) | (y > x)J°™"*") = count([h(x,y) | (y > x)]*"), 
and then in parallel, 
if (x 2 0), 
increment count([h(x,y) | (x 2 0)]*"e") by 1 
and if (y > x), 
increment count({h(x,y) | (y > x)J®™*") by 1 
execute body of operation h 
ht, in parallel, 
if (x 2 0), 
increment count([h(x,y) | (x 2 0)]**") by 1 
and if (y > x), ‘ 


increment count([h(x,y) | (y > x)]}™") by 1 
That is, if both qualifying predicates (x 2 0) and (y = 5) are satisfied for an activation, then 
both entry conditions must be simultaneously satisfied before its enter event. If only one 
qualifying predicate is satisfied, then only the entry condition corresponding to that 
qualified gate must be true. If neither predicate is satisfied, then the enter event can occur 


without delay. In any of these cases, count([h(x,y) | (y > x)J@"") is incremented if and only 


if (y > x). 
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Thus far, the discussion in this id a has relied on an informal, intuitive idea of the 
meaning of the solution specification. This section n present the formal definition of the 
semantics of solution specifications. As was the case for the problem specification language, 
whose formal definition was presented in Section 26, the ‘semantics of the solution 
specification structure are defined by specifying which histories are valid with respect to any 


particular solution specification. 


A qualification is a predicate ona vedios of saiaiisier The domain of qualifications 
is denoted Q. One particular element of Q is the predicate that atways returns TRUE. By 
considering this special predicate to be the oe associated with what until now has 
been called an “unqualified” gate, we are able to consider all gates to be qualified. So, a 
gate is a pair <ec, q>, whose first component ec is an event class and whose second 


component gq is a qualification. 


A state is a function from gates to non-negative integers. A state maps each gate into 
the count of the number of passages through it. A condition isa predicate on a set of states. 
If the condition refers only to the current state, then the argument to the condition is a 
singleton set containing only the current state. When a condition refers to previous states as 


well, each of these states must also be in the set. 
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A solution specification consists of a set of gates, and a condition on each one of these 
gates. (It is simplest to take the view that a solution specification assigns each request and 
exit gate, and every enter gate not explicitly given an entry condition, the condition that is 
identically TRUE.) The set of gates in solution specification ss is given by the expression 
Gates(ss). For every gate g € Gates(ss), the condition assigned to g in ss is given by 
Cond(ss, g). The set of previous states that the condition on gate g in solution specification 


ss refers to is given by PrevStates(ss, g). 


A history is valid with respect to a solution specification if. for each event in the 
history, every solution specification condition that applies to the event is satisfied at the 
point in the history at which the event occurs. (Actually, only enter events have non-trivial 
conditions, but for the sake of uniformity, it is easier to define the concept in terms of all 
events in the history, To define this formally, it is necessary to have functions that map 
filstories into states, i.e. into functions from gates into counts. The function CurSt maps an 
object history, the sequence of events associated with a given object, into the current state of 
that object. Recall that an object history is either the empty sequence [ ], or else is obtained 
by adding an‘event onto some other history. An event is represented by a four-tuple of the 
form <p, t, n, a>, where p is the operation name, t is the event type, n is the activation 


number, and a is the vector of arguments. The definition of CurSt is: 


CurSt({}) = A (ec,.q). 0 
-‘CurSt{add(h, <p,-t, n, a>) = X (ec, q). lif <p, b> se¢ Aga). 
then... (CurSttaXec, q) + 1) 
else. CurSt(hXec, q)) 
The notatien used pave is taken from A-calculus. The: formula "h(x, y).:.F” represents the 


function of arguments x and y whose. body is given. by. F. 


The function MosRecSt (Most Recent State) adpeen object hidiory and a gate into the 
"state of an object at the time.of the most recent.event.at that gate:. 
MosRecSt({ ], <ec,q>) = A (ec,-q), 0 
MosRecSt(addth, <p, t, n, a>), <ec, q>) = if <p,t> «ec A. qfa) 
» then, CurSath) 
ome: _ else MosRecSt(h, <ec, q>) 
The SuRRent state after history h becomes the most.recent state for any gate that applies to 


the event added onte h. 


It is now possible to formally define the validity of a history h with respect toa 
solution edcion ss. This is given by ValidSS(h, ss), where: 
ValidSS({ J, ss) = TRUE 
ValidSS(add(h, <p, t, n, a>), 88) = ValidSS(h, ss) A 
V (ec, q) (<ec, q> € Gates(ss) A ec = <p,t> A q(a) 
| > SatSS(h, ss, <ec, q>) 
SatSS(h, ss, <ec, q>), defined below, is a predicate that determines whether the state 


represented by history h satisfies the condition in solution specification ss for gate <ec, q>. 
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Therefore, the definition of ValidSS simply states that a history is valid with respect to a 
solution specification if it was valid before the last event occurred, and if the history 


satisfies the conditions for all gates that apply to the last event. 


The predicate SatSS is easy to define. A history satisfies a condition simply if the 
current state plus the relevant most recent states of the history satisfy the condition. Recall 
that the condition on gate g in solution specification ss is given by Cond(ss, g), and that this 
condition is simply a predicate on a set of states. Formally, then, 

SatSS(h, ss, g) = C(States), 
where C = Cond(ss, g) 


and States = {CurSt(h)} U {MosRecSt(h, g’) |g’ € PrevStates(ss, g)} 


_ The subject of the next chapter is the method for deriving an equivalent solution 
specification from a problem specification. Section 4.6 justifies the method presented. This 
justification relies on both the formal definition of the problem specification language given 


in Section 2.6, and the formal definition of the solution specification in this section. 


This empty page was substituted for a 
blank page in the original document. 
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Chapter 4 


Derivation of the Solution Specification 


4.1 Introduction 


The subject of this chapter is the algorithm for analyzing a problem specification and 
deriving from it an equivalent solution specification. There are two aspects to the 
construction of a solution specification. Identifying the gates required in the solution 
specification is relatively straightforward. This simply involves identifying the event classes 
appearing in the problem specification. For qualified gates to be identified correctly, 
however, this must be done after all argument constraints have been incorporated into the 


ordering clauses of the specification, as explained in Section 4.5. 


Constructing appropriate conditions to attach to the gates associated with enter event 
classes is the formidable task. The algorithm for constructing these entry conditions is the 
subject of this chapter. As explained in Chapter 3, the set of conditions on all enter gates is 
sufficient to represent the complete solution specification. The other gates in the solution 
specification and the saving of previous state information are indicated implicitly by the 


quantities appearing in the entry conditions. 


In constructing a condition for an enter gate, the basic strategy employed is to 
determine, in terms of the synchronization state, what distinguishes points in a computation 
at which an event at that gate should or should not occur. "Should occur” here can be 


interpreted formally as satisfying the predicate Sat, which was defined in Chapter 2, relative 
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to the given specification. In making this. determination, it is necessary to ssacties all 
relevant subsequences of histories, specifically those, subsequences containing the events 
mentioned explicitly in the specification. Each of these sb icnaehees, or “orderings”, can be 
classified as either valid or invalid with respect to the specification. : At each ‘point in an 
ordering at which an event occurs at the gate i in R qnenin, it is ES pesnve't to characte te the 
Sync hronivation state. These individual characterizations ant then be combined 


appropr sata based on the valelky of the orderings, to > form ano overall condition for the 


gate. 


- The paragraph above summarizes the main phase of the derivation algorithm. The 
result-of this phase, which is. presented faity.in Section 42, is the derivation ‘for each gate of 
a "preliminary condition”. For cases where the correct condition -for.a gate'can be expressed 
solely in terms of the current state, the a bidlaog cond irs is correct. When this is not so, 
the preliminary condition « can be refined by nerating 0 over r another phase of the wiperuiin 
This phase, which is presented in Section 43, uses information saved at previous States in 
the orderings as well as the current state. secion 4 44. contains ; an n example of applying the 
algor ithm of Sections 42 and 43. The one other ee of the algorithm i is some Barta 
processing designed to make the specification suitable for analysis. Section 45 describes this 
processing, in which argument constraints are incorporated into the specification so that the 
transformed specification consists entirely of ordering clauses: ‘The algorithm is summarized 
in its entirety in Section 4.6, and there a justification-is-presented for why it works. The last 
section: of this .chapter, Section 4:7, discusses the class of: specifications. ae which the 


| algorithm fails. 
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An important feature of the approach to be presented is a property that I call 
extensibility. This means that the algorithm can be applied to each conjunct in a problem 
Specification individually. If the specification s is of the form 

8, N89 NA Sr, 
then for each conjunct s; of the specification, the algorithm derives one or more conditions 
for gates in the solution specification. For each gate, the condition required for the entire 
specification s is simply the conjunction of the conditions obtained separately from the 
conjuncts s;. This property can be proved in terms of the formal semantic definitions of the 
problem specification language and the solution specification. Informally, it is true because 
each conjunct in a specification represents a separate constraint that must be met by any 
valid history, so that the overall specification represents a set of constraints, all of which 
must be met. If each constraint is implemented by a different set of solution specification 
conditions, then the joint overall constraint must be implemented by conjoining all these 
conditions. This is because an event may validly occur only if it does not violate any of the 
individual constraints. For this reason, the analysis of specification s can take place on each 
relatively simple conjunct separately, rather than on the entire, more complex specification. 


With regard to any reference in this chapter to specification s, the reader should understand 


that s can represent a single conjunct that is being analyzed individually. 
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4.2 The derivation algorithm * - 


This ne desttibes the sins of bi derivation sieeuivn It is assumed that the 
problem specification consists exclusively of ordering information, in that all clauses, as 
; defined in Section 2.5, are ordering clauses of the form (e, = eo), where events e, and eo 
refer < procedure activations for which arguments are not listed. That is to say, there are 
no aieumnent constraint clauses, nor are arguments explicitly given for any procedure 
activations. The conditions derived for the solution specification in this phase of the 
algorithm refer only to the current synchronization state, and not to any previous states. 
When any of the preliminary conditions derived by this phase is inadequate, then previous 
State information must be used in order to refine it. The method for doing so is presented 


in the section following this one. 


The algorithm is presented here on a step-by-step basis. Each step first is described as 
it works on a general specification s, and then illustrated on a particular specification. The 
specific example used for illustration purposes is example 4 from Section 2.7, which will be 
denoted here as specification s;: | 

pens! => qn" > pj" => qn. 
As discussed in Chapter 2, the effect of this specification is to give executions of procedure 


Pp priority over those of procedure q. 
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Given a problem specification § the first step in deriving the equivalent solution 
specification is to identify Evexp(s), the set of event expressions.appearing. in s. Informally, 
this set can be constructed simply by. noting which event expressions are contained in. the 
specification. The recursive definition.of Evexp(s), which was presented. in Section 26 and 
is repeated in Figure 4.1 .below, can be. used to formally construct Evexp(s) for any 
Specification. For the éasinpie Specification, 


Evexp(s}) = fpr po, qs. 


Once Evexp(s) has been constructed, the, next step. is to construct the set of possible 
time orderings among the events represented by these expressions. Suppose a history 
contains events that correspond te the event expressions ‘in the specification. Formally, 
using the definitions of Section 2.6, this means that there is some interpretation mapping 
-the event expressions in Evexp(s).into. a subset of the events in the history. Then whether 
or not the. history. satisfies. the specification. under. this. interpretation depends. upon the 
order among exactly these events. To analyze all..possible histories that involve events 
corresponding to the expressions in the specification, it is sufficient to analyze all possible 


subsequences of these events: A subsequence of events in a history. is called a sub-history. 


Figure 4.1. Definition of Evexp(s) 
Evexp(exp, rel expo) = { }, for rel € Rel 
Evexp(- s) = Evexp(s) 
Evexp(s; op So) = Evexp(s;) U Evexp(so), for op € Op 
Evexp(3 x (s)) = Evexp(s) 
Evexp(V x (s)) = Evexp(s) 


' Since ‘each relevant event is represented by an ‘event’ expression ‘Appearing in 
specification s, the sub-histories of interest correspond to the possible sequences of the 
expressions: in Evexp(s). Each sequence: of event ‘expressions ‘that’ ‘represents a possidie 
sub-history is called an ordering. Every history ‘containing ‘events represented by the event 


expressions of Evexp(s) corresponds to exactly one-of the ofderings. 


If the size of Evexp(s) is n, then here are of permutations of thee n events, but not all 
of the corresponding sequences are necessarily possible time orderings. To be a possible 
ordering, a sequence must obey the basic constraint _ 

un, = aor = um 

for every procedure activation Um: For enaripte: consider a case where 

Evexp(s) = {x,/e@ett, x, smter, x. enity, remest, y, enter, 5, ent), 
While there are 720 permutations of these six evenhts;‘onty 20 sequences represent possible 
‘time orderings. An additionat constraint’ tht must be'ritet’ by any ordering-is that © 

| (m<n)D (ur ad rom, . 
since the numbering of procedure activitions is based ‘onthe order of the respective request 
events. Thus, for a specification in which x; joo anid x, ys adam both appear, xe must 
precede x; A le ace in every ordering. These constraints are exactly the ones embodied in the 
predicate Possible defined in Section 26. Ruling out all isis that are + impossible 
corresponds to restricting attention to object histories that are possible according to that 


definition. 
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Formally, the construction of the possible orderings among the elements of Evexp(s) 
can be carried out in two stages. The first stage consists of generating all permutations of 
the elements of Evexp(s). Then every permutation that violates one of these basic 


constraints is eliminated. 


For the example specification s,, Evexp(s)) contains three events, as already noted. 
Although there are six permutations of these three events, only three are possible time 
orderings, since the other three violate the constraint that p,ewes! = pj". These three 


possible orderings are: 


(1) pecs = as = qr" 
(2) por = qe = poe 
(3) ral => p,evest => panter 

That is, in any possible history in which there are events corresponding to the three event 


expressions in Evexp(s;), these events must occur in exactly one of these three orders. 


Once the possible orderings of the events associated with specification s have been 
constructed, it is necessary to separate them into two classes. Those that satisfy the 
Specification s are termed valid orderings, while the rest are invalid. Validity of an 
ordering with respect to a specification s can be determined by simply evaluating the 
formula s. In this evaluation, either TRUE or FALSE is substituted for each expression of 
the form (e; => eo), depending upon whether or not event e; precedes event eo in the given 
ordering. Since it is assumed that by this point the specification consists entirely of 


ordering information, the result of this evaluation must equal either TRUE or FALSE. 
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The ordering is valid when the formula-evaluatés to TRUE, and ‘invalid when it is FALSE. 
In terms of the formal semantics of the prablenr specification tangivagé presented in Chapter 
".. 2,0 this corresponds to: evaluating the. predicate Sat for- an otherwise valid ‘histoty ‘that 


contains the given ordering as a sub-history under an arbitrary interpretation. 


For the example, substitution of ordering (1):into specification 5; yields the formula — 
“TRUE D ‘TRUE, Mae 
which evaluates to TRUE. Substituting- ordering’ (3) intos; results in the formula — - 
FALSE > FALSE, 
which also evaluates to TRUE. Orderings (I) and Vale are therefore both valid with respect 
to oo Substituting ordering (2) into s), however, yields —_ 
« TRUEDS FALSE, ; | 


which is FALSE, so ordering (2) is invalid. 


In describing the next ‘step-of the algorithm, some defirtitions are needed. A prefix of 
a sequence is simply any initial sere saisaEn = si eae case i the ih ch bas er which is 
a prefix of rey sequence. Any two sina have a 2 unique 1c longest matching pg which 
they share. Given two different orderings of n lia there is a ae k, where a < a <n, 
‘sich that ‘each of the first (k - 1) events in the two orderings are sere’ and ine k-th 
events differ. The shared pretis of pa C - - is the ager matching prefix . the two 


' orderings. 
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It is necessary to compare each invalid: ordering with all of the valid orderings in turn. 
In each. case, there will:be a longest matching: prefix. that the: two ‘orderings. share, which 
-;may be the empty sequence. Of ail these longest matching prefixes, we ‘choose the one with 
the greatest length. If this prefix is of length (k - 1), then the k-th event (more precisely, the 
k-th event expression) in the invalid ghee is the ofenaing event of that ee The 
offending event is the one at which the invalid ordering first “goes hong: in the sense of | 
violating the specification. That is, it is at this point in the sista} that the Sat predicate is 
first violated for the specification Assuming that the ¢ offending event is in an enter event 
| class, a + condition must be attached to the gate ive that event class in the solution 
specification, s so that the SatSS Bee er th the solution specification is is also violated at chi 


point. 


If the offending event in the invalid -ordering is not. an, enter event, then the 
Specification is illegal, in that it does not agree. with the basic. guardian model being 
employed here. According to the model, only enter:events. can be conditional and so be 
delayed from immediately taking place. If.a specification ‘implies that. some request or exit 
event should be delayed, then it represents a. property that. is incompatible with. this model. 
"Such a specification cannot be analyzed by the method presented here. (These cases are 


discussed in section 4.7.) 


Returning to the example specification s), orderings (i) and (3) have already been 
shown to be valid, and ordering (2) to be invalid. For orderings (1) and (2), the longest 
matching prefix consists of the sequence of length one whase-only element is p;"***'; for 


orderings (2) and (3), the longest matching prefix is the.empty sequence. The longest prefix 
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of ordering (2) that matches some valid ordering is therefore the one-element sequence 
[p;*""*'].. The offending event-in (2) is the event immediately following this prefix, namely 
qn" Thus a condition is required on the gate for the 4°" event class to prevent this 


invalid ordering. 


In the: general case, a een saiink be derived for each event class that contains an 
offending event in one or more invalid arenes When this condition is a peed on the 
gate for that event class in the solution specification, it must prevent any sub- -history 
corresponding to one of these invalid orderings, but allow any of the valid orderings as 
ciao shiskories The derivation of the condition requires the stave, Le. the spaclacotivatian 
State of the object, to be characterized for each invalid ordering at the point at which the 
offending event occurs, so long as the offending event belongs to the given event class. The 
method for characterizing the state is explained below. A- disjunction of these state 
characterizations is formed, to be denoted here as D;. Dj represents a general state 
' characterization of when the occurrence of a event in the given event class would fail to 
satisfy the specification. Similarly, the state must be characterized for each valid ordering at 
the point 7" which an event in the class occurs. The disjunction of these characterizations is 
denoted D,, which is a general characterization of when the occurrence of such an event 


would satisfy the specification. 


The expression given by the formula (Dy A (> Dj) represents a preliminary possibility 
for the condition required in the solution specification. The term (~ Dj) guarantees that the 
expression is strong enough to exclude every invalid ordering. Conjoining the term Dy 


aids in the simplification of the formula. Since any conditions that are trivially true in all 
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orderings of interest appear both in Dy. and in+D,, such conditions cancel out in the 
conjunction of D, with the negation of D;. These‘ conditions may arise from the fact, for 
instance, that at the point just before an event in the p*™™ class occurs, it is always true that 
count(p'*4**!) > count(p*"*"), since there is at least one activation (the one under 
consideration) for which the request event, but not the enter event, has occurred. Thus, 
this clause is a component of every state characterization, whether the ordering is valid or 
invalid. The conjunct D, guarantees that the negation of this clause is ‘eliminated from the 


condition. 


The preliminary condition given by (Dy A @ D,)) is ciawa to be at least as strong as 
the condition required, since the term (~ Dj) excludes alt invalid orderings, ie. all histories 
with sub-histories corresponding to an invalid ordering. ‘The condition must be tested 
against all ‘the valid orderings, however, to check that it is weak enough to allow ail of them 
as sub-histories. This checking is accomplished ‘by: determining that the condition is 
satisfied at the point at which the appropriate event occurs ify each valid ordering. If the 
condition is satisfied at all these points, then the-condition is correct, and the task is 
completed. If this is net so, then the condition is too ‘strong, in’that it rules out some 
diaerines that are valid according to the specification. When this ‘happens, steps must be 
taken to refine the condition by weakening it:appropriately.. This weakening ‘process will be 


described in the next section. 
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In characterizing the synchronization: state. of the:object:at a point in an ordering, the 
_ ordering must be considered to representa subrhistory: that is embedded within: some 
possible history. Except for what can be-deduced from the. erdering-itself, nothing can be 
assumed about the history or about the jaieripcekalse by: whic the event expressions in. the 
ordering are mapped into the,events in the history.. There:may-be-an-arbitrary number of 
| events in the histery preceding the .sub-history,oand .between. any two. events..in the 
sub-history. It is known, however, that the history:is-pessible. Also, the. history can be 
assumed to be compatible with the solution specification structure, since if it is not, then-the 


algorithm cannot succeed in any case (see Section 4.7). 


The characterization of the state Aherefore: relies entirely on; the ‘other events in the 
sub-history represented: by -event expressions .in- the. ordering... Since. the characterization 
involves actual events.in a history, rather than.the eyeat expressions in. an ordering, .¢ach 
event expression. conceptually..is.replaced by a real-event, sa;that: every Variable within an 
expression is replaced by an actual -value. Since. the .interpretation- for making these 
replacements is arbitrary, however, neikianaan, be-assumed abput the values. All that is 
known is. that for any given history and interpretation, there is some particular value for 
each variable. For this reason, in the state characterization cach variable is. existentially 
quantified. That is, every state characterization formula is-of the form: 

3 (ip, ip) CS), 


where {ij, ... , ip)} is the set of variables appearing free in formula S. 
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The body S of the state characterization formula consists of placing bounds on the 
counts of event classes, based on which of these events occur before and after the point at 
which the characterization is being made. It is assumed that the chardeierization is made 
just before the enter event of interest occurs, so that this vent tae oe not yet taken place, 
but every preceding event has occurred. The characterization contains a clause 
corresponding to each event in fe ordering, ‘eat is, to each element of Evexp(s). For each 
ec Evexp(s), the count of the event oles containing e is given either a lower bound if e 


occurs prior to this point in the ordering, or an upper bound if e occurs subsequent to this 


point. The bound in either case is the invocation number of e. 


For example, let.e be the event expression Rens. If event. x-_tnte occurs prior to the 
enter event in the ordering being considered, then the state characterization contains the 
conjunct 

count(x*"*") > m. 
The reasoning is that if x,,°"*” has already occurred, then so have each of x,°"'*" for (I < k 
< m), So that count(x*"*’) is at least as great as m. ‘The count may be greater than m, as 
other events in the x*"ter class may have taken place in between event X*"e’ and the 


current point, but it is not less than m. On the other hand, if x one occurs after the point 


' 


at which the characterization is made, then the clause becomes instead 


count(x®"*") < m. 


If x,,°"'*” has not yet occurred, then neither has x,°"*" for any k > m, so that count(x®™*") 


i 


enter 


must be less than m. Again, other x events may occur in between the point of the 


enter 


characterization and Xm 80 that the count may be less than (m - 1), but it is certainly 


less than m. 


This method of state characterization relies on a first-come-first-served scheduling 
enter 


discipline at each gate. That is, it assumes that any history occurring prior to event x,, 


contains exactly 


te, xo, ae X enter) 


m-l 
as the subsequence of events occurring at the x°"'*" gate. This scheduling policy is built 
into the structure of the solution specification, and so it may be assumed that if a correct 
solution specification can be derived for a specification, then it must fit this structure. 
There are specifications with which this first-come-first-served scheduling policy is not 
compatible, and the derivation algorithm fails to derive a solution specification in such 


mn 


cases. This point is discussed more fully in Section 4.7. 


Since every state characterization formula is of the form 
J (ip, ip) CS ), 
the construction and manipulation of the formulas D, and D,; must make use of logical 
properties of existentially quantified expressions. Because of the negation of D, in the 
preliminary condition, universally. quantified expressions ‘uid also be manipulated. A 
summary of the important logical properties used for simplifying these formulas appears in 
Figure 4.2. Properties (El) through (E6) are equivalences applicable to existentially 
quantified expressions, and properties (Al) through (A6) are their dual forms for universally 
quantified expressions. (Qi) and (Q2) apply to formulas involving both types of quantifiers, 


and (DI) and (D2) are the distributive laws for A and v. 


Py ee 


Figure 4.2. Logical properties af quantified expressions 


(E2) 3 (i,j) (AG) A Bj) # i (Ali) A 345 (BQ) 
(E3) J (i,j) (Ai) # 3 i (Ai) 

(E4) 7 (3 i (S)) # VWi(-S) 

(E5) Ji (x 2i A y<i) # (x >y) 

(EG) 3i (x < i) # TRUE 

(A2) V (ij) (AG) Vv BQ)) # vi (A(i)) v Vj (BQ) 
(A3) ¥ (i,j) (AG) # Vi (A(i)) 

(A4) = (Vv i (S)) # 3i(-S) 

(A5) Vi(x <i Vv y2i) # (x <y) 

(A6) Vi (x 2 i) 4 FALSE 

(Ql) 3i(S) A Vi(-S) # FALSE 

(Q2) Ji(P A S) A Vi(Q v 7S) # 3i(P AQ” S$) 
(DI) (x A y) v 2) #  ((x viz) A (y v 2)) 
(D2) (x vy) A 2) # (x A z) Vv (y “A 2)) 


Let us return to the example for an illustration of the above discussion. Recall that 
the offending event in the invalid ordering is qn". and so a condition must be derived for 


enter sate. In ordering (I), the event qe is preceded by events p,°%*"' and p,°"*", 


the q 
and has no events following it. Therefore, the state characterization c; is: 

3 (i,j) (count(p’eves!) > i A count(p*™'*") > i A count(q®"*’) < j), 
where the first two terms in the body-are obtained from the events preceding qn. and the 
last term from the fact that Ger itself has not yet occurred at the point at which ‘the 
characterization is made. In ordering (2), the event deo is preceded by p,°¥*5' and 


enter 


followed by pj,“ so the state characterization Co is: 
3 (i,j) (count(p'e**!) > i A count(p*™"*") <i A count(q**’) < j). 


_ In ordering (3), qane precedes both p;"*’**' and p,°"*", and the state characterization Cg is: 


a 78 * 
3 (ij) (count(p"""), <i A..countip?"*") < i A countlge"*) < j).. 


These individual characterizations an now be combined to. form the terms D, and 
D,. The disjunction for the valid orderings D, is equal to (c; V cq), or gt seen ts 
3 (iy) (count(q*"**) <ja- 
((count(p"***!) > j A count(p**) 2 i) v 
(count(p™™ < ia count(p*"*) < i))). 
The disjunction for the invalid orderings Dj is simply Co, So that (- Dj) becomes 
V (ij) (count(pe") <i v count(p™*’) > i v count(q*™*’) 2 j). 
The formula for the preliminary conilition is therefore given by Dy a (Dj), or 
3 (i,j) (countiq?*") <j A ; 
—— (count(pe**) > 4A count(p™*) 2 i) v 
(count(p'**"}) <i A count(p*™") < i) A 7 


V (i,j) (count(p’e**") <i v count(p*"*) 2 i v count(q*"*’) > j). 


This formula can ‘be simplified. Since the terms involving i-and j are independent in 
both of the quantified expressions, they can be separated, using ‘logical properties (E2) and 
| (A2) from Figure 4.2. Fhiés yields the formula: 
3 i ((count(p’™) 2 i A countip™”) 2:1) v 
(count(p’***!) <i A count(p"™").< i)) A 
2 j (count(q?"™) <j) A 
(¥ j (countiq*"*") 2 j) v 


Vi (count(pe*") <4. ve count(p™™) > i). 


-- 


By distributivity property.(D2), this is equivatent to 
(3 i (count(p***') > i A count(p*™*):2 i) .v 
(count(p"*™**!) <i a count(p®*) < i)) A 
3j (countiq'") < ) A 
vj (coung™") 2 2 » 
v 
(3 i (count(p™"") > in count(p*™*") 2i)v 
(count(p'*") <i A count(p*"'") <i)) A 
3j (count(q*"*") <j) A 
vi (countip™™™) < <iv -eountipt™) 2 2 D) 
The first dixjanet is simply FALSE, since it contains the oA MinciOn” of 
3j (count(q’"*") < ) 
and | 
V j (count(q*"*”) 2 j): 
This means that the formula reduces to the second chun, 
| ai (count(p"™*"") 2 >i A -countipt™ zi) Vv 
‘(count(preetty <i A countip"™™ < 0) A 
3j (countiqr*" < ’ rs 
| Vi (count(p'*™**") <iv _eountgn 2 > ». 
‘ Each of the first two conjuncts simplifies to TRUE, so the entire formula reduces to 
Vi (count(p'e**) <i V count(p?"*") > i), 
which is equivalent to | 


count(p®"") < count(p*™*") 
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by property (A5). Using the @ priori fact that count(p™") 2 count(p’™”), the preliminary 
condition can be simplified finallytx © © a 


count(pr") = count(pe™"). 


To determine whether the preliminary condition is indeed correct and not overly 
strong, it is necessary to test it at the appropriste sah ii each of the valid orderings. The 
valid orderings are (1) and (3). At the point of event “nr in each of these orderings, the 
condition | 7 | ; 

count) = counipr™) 
is satisfied, showing that it is $ weak cee to pala both valid orderings. Because of the 
conjunct (~ Dj) in the condition, it is guaranted to Pe rong enough to nee the anvalic 


ordering. Tecae: it is scictiy the condition require for gate q enter, and a correct 


solution specification has been constructed. 
4.3 Use of previous states 


In the example presented in the last csiiais? the current state alone was sufficient to 

Peeara tite Vara a 
derive the condition reguited in the solution 0 specication, The Purpose of this section is to 
explain the method employed when this is not oe case, and one or more previous states 


must be used as well. Information from previous states is weet to refine a preliminary 


" condition that is too strong so ‘that one or more as orderings do hot aca it. 
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An overly strong: preliminary cevivitided weakened by disjoining one or more terms 
to it. The new. condition that résults is:strictly weaker than the prelimmary condition, since 
it is the disjunction: of the preliminary Condition and-other ‘terms. All valid’ orderings that 
satisfy the preliminary condition therefore automatically satisfy the new condition. The 
purpose of the weakening terms is to include the remaining valid orderings as well. For 
this reason the analysis for auruding a weakening siti ‘an disregard the valid orderings 
satisfying the sieiiildayy Senaition: Only the remaining valid orderings not permitted by 
the preliminary dcriaitiony need be sbvidiciered| along ‘wnt all invalid orderings for which fie 


event in question is the offending event. 


Each weakening term shares the property with the prelintinary condition that it is at 
least strong enough to exclude every invalid ordering, a herefores:® all hat heed be checked 
for each weakening term is which yang ‘orderings that ha have thus far been excluded are 
permitted pyre the given term. The send terminates wien the condition is weakened s so 


that all valid ‘orderings 3 are allowed, or “else, when no further + weakening terms can be 


constructed. 


In deriving a weakening term, it is metessary first to find some event that precedes the 
enter event in question in each ordering being considered, ie. all of the valid orderings not 
satisfying the preliminary condition plus all of the invalid orderings in which the enter 
event is the offending event. This event may be in any event class, and is not limited to 
enter events. Once such an event is found, the weakening ae is constructed in much the 
same way as the preliminary condition, but using state characterizations at this previous 


event. The state is characterized at the point of the preceding event in each of these 
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orderings (but not in any of the other valid orderings). Notice that each of these 
characterizations, rather than involving ordinary counts of event classes, concerns quantities 


of the form [count(ec) @ g], i.e. counts of event classes saved at the event at gate g. 


At this point the characterizations from the valid orderings are disjoined to form a 
new expression D,’, and the characterizations from the invalid orderings are disjoined to 
form D;’. The ferimula (D,’ A eS D,)) is constructed and used as a weakening term by 
disjoining it to the preliminary condition to form a new condition. This new condition is 
tested to determine whether the valid orderings excluded by the preliminary condition are 
allowed as a result of the weakening term. If all these orderings are permitted by the 


weakening term, then the new condition constitutes the solution specification condition. 


If there are still some valid orderings not allowed, then the process is repeated on the 
valid orderings still excluded. Here, however, each characterization refers to both the 
current state arid the previous state. That is, each characterization involves both current 
counts and counts in the previous state. The weakening term (D,’ N(- D;)) is formed in 
the same way. This term is again tested on the excluded valid orderings, and disjoined to 


the condition if it is satisfied by any of the excluded orderings. 


For example, consider the specification 
( exit enter) > , 
Pj Pj 
it t t 
3 k (pj; => qq" er => Pp sah 
When the preliminary condition is formed for gate p*"*’, it is found not to satisfy the valid 


ordering 
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() p,™" => ¢, one =p 
A weakening term must ‘therefore: be: constructed for this ordering. The two invalid 
orderings are | | 
(2) pi =p iner => gy omer : 
(3) q,oner => pj = poner "ages 
in both of which the offending event is i. The'trie event that precedes pi" in each | 
of these three orderings is p;°"". The state characterization at this‘event in each of the 
three orderings is: | 
cy: 3 (i, j, k) (leount(p™") e p®"] <i a [count(q*"" Je p*"} <k 
A feount(p*™) « p***) <j): 
Co: FU, j k) Ceount(p™) e pe} <i ~ [count(q?™) e p*"] < k 
A- [count(p™*") @ p*“) <j): 
cg: 3 (i, j, k) ([count(p™") @ p™] <i A [count(q?""*") ep™)2k 
A fcount(p*"™) « ont D | 
However, the formula (D,’ 4 (> D;’)) given by 
cq ACA (co v C4) 


is equivalent to FALSE, which is obviously useless as a weakening term. 


Therefore, it is necessary to form new: characterizations of, both the current and 
previous states. These are given by: | - | 
cy: 3 (i, j, k) (count(p™*) 2 i A count(q’"*’) 2 k A count(p*""*") <j 
A feount(p* e p™"] <i A [count(q*™*’) e emt] <k 


A {count(p*"*’) e pe") < j) 
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co's 3 (i, j,k) (count(p™) >i. reowatige™™).< kA countipe™') < j 
~~ A [countlp*"").¢ or ih koount(qtt) a:p")< k..- 
A [count(p*™*") e p*"*) < j) 
cy": 3 (i, j. k) (count(p™*) 2. i- rreountig”™) 2h A count(p™) < j 
A [count(p"#)e p*™) «< 1 Seonmnlge ep™)2k 
A (count(p"™™) ep?) <2 a ee Se 
The new weakening term (D,’.A.(7. Dp) pene ee 
| cy A (= (cg’ V cg), 


which simplifies to ae ee ve 


count(qr™**) > [countiq’'*). = p°""), 
which does satisfy ordering €i).;.As a result, the solution specification condition is given by 


disjoining this term to the preliminary condition... 


If neither of the weakening te terms oprained asa sek of a given previous state is 
sufficient to include all of the remaining g orderings, then ‘another pla event must be 
found and the entire weakening process is repeated using the state at that event. Since this 


may involve using the next-to-most recent, etc. event at a pear gate, a notations! 


extension is needed to ceter to such quantities, such as s [count(ec) ee gh ees 


The idea behind the method is to ‘find 3 some © property that Aiinguishes the valid 


orderings from the invalid ones. Unless the Laces is one that violates the underlying 
model, it is always. "possible to find such a Property. A valid ordering that cannot be 


distinguished on the basis of the preliminary. cuadiGous must ‘differ from an invalid 
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ordering by the exact ordering of previous evertts, rather than’ by their absolute number. 
At some previous event, then, certain other events must have occurred in the valid ordering 
but not in the invalid ¢ one, or vice versa. Using & the state at that point allows the two to be 


‘ ret f 
distinguished from each other. Using only the previous state allows a wareiing term to be 


constructed that involves only the relationships ps! quantities at that hang event. 
When this is not sufficient to distinguish all valid orderings, then characterizing both the 


current and the previous state permits relations: to be formed between current and Bieviovs 


quantities. 


The weakening precess is repeated until-one of:two things happens. If every valid 
ordering is allowed, by either the preliminary condition invelving the current state or else 
by a weakening term involving some previous state as well, then a correct solution 
specification condition is thereby obtained. If instead, one or more valid orderings are still 
disallowed, and no event can be found that precedes the sues event in question in both the 
disallowed valid srderingts) and all the invalid orderings, then the algorithm fails in 


constructing a condition. A discussion of situations in which the method fails will be 


postponed until Section 4.7. 
4.4 An example using a previous. state 


This section contains an example of applying the algorithm as it has been presented in 
Sections 4.2 and 4.3. The example chosen is ong for which the current state is insufficient 
for expressing the solution specification conditions, and previous states must be used. The 


specification to be analyzed here is example 7 from Section 2.7, to be denoted so: 
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(aener = ber) e (<o"" =>d eal 


The first step in the derivation process is to identify the set of event expressions in the 
specification. The set of event expressions in this case is given by 
ra rc oop 
Evexp(so) : fai" er bj "oe ", dj , ery | 
The next step is to construct all possible orderings among these event expressions. In this 


example there are no two events associated with the same procedure activation (such as 


vequest 


Pi and p,°"*'), nor are there two request events for the same procedure (such as 


request 


Pj and p,,;"°*"'). Therefore any of the 24 permutations of the four events in 


Evexp(so) represents a possible ordering among them. These 2¢ orderings are listed in 


Figure 4.3 and numbered for the sake of future reference. 


Each of the constructed orderings is tested against the specification to determine 
whether it satisfies the specification and is siaherore valid, or fails to satisfy it and is 
invalid. For example, in ordering (6), (a°"" => bon) and (c,°"" => a) are both 
FALSE, so that specification so evaluates to the expression - | 

; FALSE # FALSE, 
which is equal to TRUE. Ordering (6) therefore satisfies the specification. When the 
specification is evaluated for each of the first 12 orderings, it evaluates to TRUE, showing 


each of these orderings to be valid. Each of the last 12 orderings causes s to evaluate to 


FALSE, though, so that these orderings are invalid. 
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Figure 4.3. Possible orderings for specification 59 
(1) aoe Ss byrne ace ener = dort 
(2) a ener => center a bynter = ays 
(3) ae = ere = denier = ber 
(4) bene aes aiontes nis ater a ices 
(5) Bienee => aynter = ia = eenier 
(6) bre aR ale = eens as ante 


(7) center => d.enter => q.enter = b.enter 
t J 1 


(8) center => a .enter = enter = b.enter 
i i J J 


(9) center => a.enter = b enter => d_enter 
1 1 J J 


(10) ajener = eer = boner = aot 
(11) ajenier = bene = ee = acne 
(12) ar = bye = ante = enter 
(13) ater an a = qe 25 center 
(14) ae => co = boner = een 
(15) a ante? ax deny = eener ak bene 
(16). bjenter => ater > center ap ase 
(17) laa => Gor = ajenter = a nite 
(18) Ene ay genes => ajenter > gee 
(19) aa = ajener => boner = ane 
(20) ¢erter => bjener =s i = acter 
(21) gener = bp = ante oi aire 
(22) aerlor —p cyerter —p g,etter —> panto 
(23) acae = gente a Estee om bent 


(24) ae pare a =<» bee pen atid 
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The offending event in each invalid ordering can be identified: by comparing the 
ordering with. all the valid orderings to determineat what point: the invalid ordering first 
fails to satisfy the specification. For example, invalid‘ ordering: @3) matches valid ordering 
(1) as far as the first two events are concerned. Sines this is the longest prefix that does 
match the prefix of some valid ordering, the 5 next “event in 03), nantly an, is the 
offending event. When this is done for each of the 2 invalid orderings, it is found that the 
offending event is aon in siderines (13) through | (5). ¢ cj enter cin (6) trough (18), by enter in 


(19) through (21), and a;*"*" in (22) through (24). 


A condition is needed for each of the four enter ore mentioned in the specification. 
Here the condition for the a®"* gate will be derived, ‘To determine the condition for this 
gate, it is necessary to characterize the state at event a ote in each of the 12 valid orderings 
as well as in each of the orderings in which it is the offending event, namely (22), (23), and 
(24). The characterizations one obtains for all of these orderings, using the characterization 
method described in the previous section, are listed in Figure 4.4, witty characterization: ¢; 


applying to ordering i. 


The formula dist is obtained from disjoining the ditties cj through co is 
given by | 
3 (ij) (count(a®") <i a 
((count(b*"""’) < ja count(ct™er) > i) Vv 
(count(b*™*’) > j A count(d*™") > j) v 
(count(c*"*") <i A count(d*™*) < jp». 


This formula is D,, which represents a characterization of when the occurrence of such an 
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Figure 4.4. State characterizations at event a," 


Valid orderings 


C19: 
Cy: 


C19! 3 (i,j) (count(a®"'*") < i 


: 3 (i,j) (count(a 


: 3 (i,j) (count(a 


: 3 (ij) (count(a 


enter) <i 


: 3 (i,j) (count(ae’).<4 | 
: 3 (ij) (count(ae') < i- 


> a (i,j) (cou nt(ae"*") <i 


enter) <i 


> Bij) (count(a®™""') < i 


: 3 (ij) {count(ae) <4 - 


enter) <i 


> 3 (ij) (count(ae™*) < i 


3 (ij) (count(a™*") < i 


3 (i,j) (count(a’"*") < i 


Invalid orderings. — 


Coo: 3 (iy) (count(a®"*") <i 


Co3: 3 (i,j) (count(a®"'*’) <i 


Co4: 3 (i,j) (count(a””’) < i 


N 


A 


A 


AN 


“ 


count(b*"") <j A 


count(b**") <j” 


-count(b*"'").<j A. 


count(o""™") 2 jn 


count(b*™*") 2 j A : 


count(b®"*’) > ja 


count(b®™*") <j a. 
count(b*"*"") <j A 
count(b*"") <j A 
count(b™") 2 j 
count(b°"'"’) 2 j AN 


count(b*"*") 2 j A 


count(b*"*") <j A 


count(b*™*") <j A 


count(b*™'*") <j A 


count(c®"'*") < j 


“coun t(co™ery Pas 
count(ch™*") <i - 


coumt(er™) <i 


count(c*™*") < i 


count(c®**") > j 
count(c®™!"") 2 j 


count(c*"'*) > i 


count(c™*") > j 


sount(cr*") 2 i 


count(c™*’) > i 


count(c***") < i 


count(c**") > i 


count(c"*) < i 


count(c®™"*’) < i 


A 


N 


an 


A 


AN 


A 


“A 


“A 


a 


A 


A 


; count(deery - ) 


count(d*"*’) % j) 


- eount(de"'*") <j). 


count(d*""*’) < i) 


count(d*"*") > j) 
count(d°"'*’) > j) 
countid®™*") > j 
count(d®"*") < j).. 


count(d*"*’) < j) 


_count(d*"*") 2 j) 


count(d®""*") > j) 


count(d®"*’) 2 j) 


count(d*"'*’) > j) 
count(d*""*’) > j) 


count(d®"*’) > j) 
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event satisfies the specification. The disjunction of Co9,.Co3 and £o4 is Dj, representing a 
general characterization of when eee would not satisfy the specification. This 
_ formula is equal to: a ee whe BR 

. Big) (countta®").< i A count(b™").< j A: count(ame).2 p. 
The body of ‘this -expression’ contains the three eonjuncts “that appear in all three 


characterizations, whereas count(e®™) is greater thati oF equiat to i in to, but fess than i in 


the other two, so that these terms cancel out. ad 
The preliminary condition that one obtains then is given by (Dy: A D)). which 
equals” 
3p (comntla) <1 A 

(count(b*"*") < ja counticr™r) 2i)v | 

‘(count(b*"ter zja count(a**) 2) Vv 

‘(eount(ct" <i k count(a*"r) < » A 

V (i,j) (count(a®"*") 2 i Vv count(b*") 2 jv count(d*""*") < j. 

The terms involving i-and j in the universally ‘quantified expression can be separated, 


applying logical property (A2) from Section 4.2. This resus in the formula 
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3 (ij) (count(at"") <i -n 
((count(b*™*") <j A count(c*™#) 2 i) v 
(count(b*™*").2 j a count(d*"*) 2 j) v 
(count(c?™*") <i A count(de"*")-< j))) A 

{¥ i (count(at™*) 2 i) Vv. 
Vj (count(b**") > j v. count(d*"*’) < j)). 

Using distributivity, this can be expanded into 

(3 (i,j) (count(at"*") <i A 
((count(b®"*") <j. A count(c*"*’) 2 i) v 
(count(b*"*') 2 jn count(d’™’) 2.j) v 
(count(c"*") < i A count(d®"'*’) <p) A 

V i (count(a®™*") > i)) 
ee 

(3 (i,j) (count(a®"*") <i A 
((count(b*"") <j A count(cr*") > i) v 
(count(b*"*7) > j A count(d*™") > j) v 
(count(c®™*") <i A count(d*""*") < » n 
vj (count(b™*") > jv count(d*"") < j)). 

The first disjunct reduces to FALSE, due to the conjunction of 
Zi (count(a"™™) <i) 


and its negation. This leaves the formula 


-%- 


3 (i,j) (count(a™") <4) « 
(fcount(b™") <j-A count(c*ery > IY v 
(count(b*™*) > j a count(d*™) >) -v 
(count(c?*") <i A ‘count(de™") < jy) A 
Vj (count(berr) > j-v eoume(arr) < j). 
This can be simplified to | 
Vj (count(b*™*") zjv count(a**") <j), 
or simply 
count(b®*"**) > count(d***’) 
using logical property (A5): ‘This ig the preliminary condition itt simplified form. However, 
when one checks this condition against each of the valid orderings, one finds that there is 
one ordering, namely (7), that violates the ‘condition.’ This means that the. preliminary 


condition is too. strong, and must be weakened sufficiently so as to permit ordering (7). 


It is at this point that the weakening method described in Section 4.3 must be 
employed. An event must be found that sebanel at, the nies event in question, in 
ordering (7) as well as in each of the invalid Seaerings for which aj"" is the offending 
event, those being (22), (23), snd (24). The single event that occurs before a;*"'*" in all these 
- orderings is ajyener, Thus, an attempt is made to find a condition at this event that 


distinguishes the valid from the invalid orderings. 
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The state characterization at. ane in ‘ordering (7) is given by: 
3 ij) (eount(a*™*) @ a=} <i A [countlb™**) ed") <j A 
[count(c"*") @ d®*") > i A feount(d*™*") @ d®*") < j) 
Since all quantities refer to the state at the d*"** event, the notation “e d*"*"" is used on all 
counts. This becomes the term Dy’ ne OU AELION o previous state characterizations for 
_ valid orderings. The characterization for each of orderings, (22), (23), and (24) is the same, 
namely . | 
3 (i,j) (lcount(a*"'*") e a") <i A [count(b® @ ar) < ja 
[count(c®*) @ dtr] <i A [eoant(d?)e asster Y<j), 
so the disjunction of characterizations D;’ is equal this as well. The proposed weakening 
term is given by (D,’ A (~ D;)), which equals | — 
3 (i,j) ((count(at*") @ enter <i) A {eountio™? . aga | <j PS 
[count(c*"*’) @ ater) > in oa e ane] <j) A 
V (i,j) ([count(a*"*") e ar} > 2iv feountiot**") e anny zjv 
[count(c*"'*") e der] > i v feount(a*™") @ getter) 2 j). 
Simplifying, this forsniata becomes 
3 i (Lcount(a®"'*) @ d®") <i) A [count(ce™") @ dee) > ji), 
which reduces to 
[count(at"*")'e d®™*"] < [count(c*™*") @ a’) 


by logical property (E5). 
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When this condition is tested im ordering {7); it is found to be satisfied. Therefore, 
this term is disjoined: tothe preliminary condition to-obtain the final solution specification 
condition: 


count(b*"*") > count(d*"*") v [count(a®™™) @ d°"*) < [count(ce"'*") @ d°*"'*"], 


The method illustrated in deriving the condition for gate a°"** must be applied again 
for each of the other gates b®*'*", c®*"* ang actter, "Due to the symmetry of the specification, 


these derivations are completely isomorphic. 
4.5 Incorporating argument. constraints 


The previous sections have presented the method for deriving a solution specification 
from the problem ia under the assumption that each ‘clause in the specification is 
an ordering clause of the form ey => €, for some events e and Cs “When a specification 
also conta ins other clauses in the form of argument o iinatalite these constraints must first 
be incorporated into the ordering clauses of the specification before the algorithm described 


previously can be used. 


To simplify the discussion, it will be assumed that argument constraint clauses appear 
‘only as conjuncts in the hypothesis of an implication. A specification that. does not satisfy 
this condition can be -transformed ‘na an equivalent’ one. that does as follows: Any 
Specification can be put into conjunctive normal form (CNF) by well-known techniques of 
first-order logic. Each conjunct (which is analyzed separately as explained peeviodsly) then 
consists of a series of disjuncts, some of which may be argument constraint clauses and at 


least one of which must be an ordering clause. The general form of such a conjunct is 


therefore: 
Nyv.Nov..v Nyy Oy V =. V O,, 
where each N; is a (possibly negated) argument constraint clause and each O; is a (possibly 
negated) ordering clause, and j.2 0.and-k 2 1. - This cati*be: transformed, using the tautology 
(x Dy) # (- x vy), into: 
(ONDA Ng) WAND) > (Ov. -¥ Oy). 
In this way, all of a argument constraint clues of the specification, some in 1 negated f form, 


are brought into the een of the emia while aul ordering clauses are in the 


8 
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conclusion of the inplication. 

An argument. constraint clause. can-involve either. invocation number variables or 
arguments to procedure activations... When a clause itivelves invecation. number dariabiek 
it simply represents a constraint on those variables appearing: in the specification....This 
constraint must be incorporated “into evesy state tharactesization. Otherwise, the clause can 
be ignored in the other steps.of the derivation process. 


goes 


As an example, consider the first conine of the ‘aketnative ‘produce: Soustiiel 
SHeetlication of example 8 in shapes 2: : 
_ ; is FY > “(aep, exit => rem Jaa 
The clause (i = j) is ignored for the moment, dnd the crderinig clause is analyzed by the 
regular method. Of the two orderings possible.on the two.events in the conjunct, the 
ordering (dep"" => remj°"""): is valid, while the other: ordering {rem => dep,""") is 
not. The offending event is clearly rem*"*", and a condition must be constructed for the 


rem**" gate. The state characterization at event rem ener in the valid ordering would be 
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| (i,j) (count(rem*"*") <j A count(dep®**) 2 i), 
except that here the clause (i = j) maist be added ‘as a-conjunct of the characterization, 
giving: er qa epee 
3 (ij) (coant(rem™) <j a count(dep’™). 24:0 (i = j)). 


This expression represents D,. 


For the invalid ordering, the state characterization at event rem onier also must include 
the clause (i = j). This formula is: 


3 (i,j) (count(rem*"*’) <j A countidep**) a4 i (i : p. 
which constitutes the formula D;. The preliminary condition : Dy KG D). of: | 

| 3 (ij) Ccount(rem™") < ¢ A countidep™) 2 kW ie j)) A 

V (ij) (count{rem®") 2 jv count(dep™) 24. v (i & j)). 
‘When this condition is simplified, it reduces to: 
count(rem*""*’) < count(dep**"),. 

which is the condition on the rem*"*: gate required in the solution specification. This. same 
condition is obtained when analyzing the specification 

| | dep," => rem ch, 
in which the same property is specified, with the equality between the invocation numbers 


of the two activations indicated implicitly. 


This illustrates the generat technique for Handling relational clauses that invoive 
invocation numbers. As it shows, such clauses are integrated in. relatively: simple: manner 


into the method previously given for constructing a solution specification, since they simply 
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represent additional information that must be included in each state characterization. For 
predicates on arguments to procedure activations, the matter is not quite so simple. The rest 


of this section is devoted to discussing how to handle such clauses. 


An additional assumption that will be made concerning relations involving the 
arguments to frotedure activations is that all such relations are made explicit. An écaigle 
of an implicit relationship is a specification involving two procedure activations p(x) and 
qj(x). Here the implicit relationship is that of equality of the arguments to the two 
activations. This can be made explicit by changing the argument of 9j to some new 
identifier y, and adding the predicate (x = y) as a hypothesis of the specification. The 
situation would be handled in ' Similar manner if the argument to qj were not x but 


instead (x+1) or any other function of x. 


Argument constraint clauses are incorporated into the ordering clauses of a 
specification by qualifying all affected procedure activations. Once a clause has been 
incorporated by means of qualification, it can be eliminated from the specification, so that 
the result of the qualification ohale of the algorithm is to transform the specification into 
one involving only ordering clauses. After this transformation has been accomplished, the 
specification contains some procedure activations that are qualified. Qualified activations in 
a specification result in a solution specification containing qualified gates. Specifically, a 
qualified gate is required in an event class for each event expression in that class appearing 
in the specification and involving a qualified activation. The conditions required on all 


enter gates in the solution specification, qualified or unqualified, can be derived by the 


method already presented. In the derivation of these conditions, the qualifying predicates 
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on procedure activations are transferred to the associated gates. Both the enter gates for 
-which conditions. are sanstructed, and the. gates. on, which counts are taken, may be 


' qualified. 


. The general form of a qualified procedure activation is: : 
fp(v). 4 CC, th» 5 tall 

_ where v is the vector of parameters to procedure ‘activation p;,.and -C is some predicate 
< involving these parameters and sdso: possibly some new variablest; through t,,, that. do: not 
appear in the specification. (The use of these "new" variables is explained below.) The 
qualifying predicate G represents-an implicit restriction on the.universal quantification of 
the invocation number i im the expression, restricting. i to those invocation: numbers for 
which the corresponding activations satisfy condition C. This means that this event 


expression can only represent events whose arguments satisfy predicate C. 


Each clause that involves only the argument to a single pracedure activation is 
. incorporated. into the specification by attaching the clause to the given activation as a 
qualifying predicate. For example, let: ¥} be the: vector of arguments to procedure p, and Vo 
be the vector of arguments to procedure q. ‘Consider the follewing specification, where C, is 
a predicate only involving: ¥; and:Co isacguielicate only:involving Vo: 
(Ci(v)) A Colve)) > 
(pivot => gv ol) >-Gp vy Pr*" => qvoy™)). 

Predicate C, can be: incorporated into.the. specification by qualifying procedure activation 
pj} So that pv) becomes | 


ipavpicdvpl 
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Predicate Co can be incorporated by: qualifying activation 4% to 
Iqfvgh Oxkegh 
This transforms the specification itself to: 
Cp tvp) L Civ 1°"! => tgiivg) Colvgd Ph") > 
(lpi vp) | Cv PM" => [q(vg): Covel"). 
The meaning of this acceas is that any activation of P ee quatsying predicate ~ 


Yas 
Cc) and any activation “of q satisfying cpm must obey the ordering constraint giet but other 


activations of these operations need not. “This is exaly the ‘meaning of the original 
specification: If cu) ahd Cog) are both true, ru, then the events must satisfy the ordering 
constraint in : order for the history containing "thot events to to be valid | If either of the 
qualifying predicates is not true, then the hisory is ‘valid according to the specification 


regardless of the order among the events. 


In deriving a solution specification for this specification, there: must be gates with 
qualifying predicate C,(v,) in the p’***' and p*™*" event classes, and a Jue with aualitying 
predicate Co(vo) in the q*"*’ event class. The ony Snditions in the solution specification 
are derived just as if AEE activations were unqualified, or that the enter gates for which 
the conditions are saecived. afd the pales on which counts are taken: must be apenas 
appropriately. Without the areument constraint ai this specification orbuld ‘be be sj, 
the example anal yreailt in Section 4.2, where the condition 

countigr count, 


enter 


was derived for gate q ‘With the predicates included in the specification, the same 


analysis results in the condition 
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count([p(v)) | Civ J") = count((p(v,) 1 Civ) P""), 
for the qualified gate [q(vo) | Colvo) rn’. That is, the qualification C,(v,) on activation 
p,(v;) results in qualifying the gates p’°™** and p™, on witich the counts are taken, with 
enter 


this same predicate. The qualification Co{v5) on activation qv) is attached to the q 


gate for which the condition is derived. 


A predicate involving arguments to more than one procedure activation is converted 
into a Sinunaion of different predicates, each of hich only involves the arguments to a 
single activation. This is accomplished by parameterizing the original predicate in terms of 
oon ae variable t. Once this is done, then ce same method of qualification as discussed 
above ai be used. For example, the predicate (x = y), where x and y are arguments to 
different procedure activations, is transformed into the two predicates (x = t) and (y = t). 
Each of these two predicates is then incorporated into the specification by using it to qualify 


the appropriate. activation. 


As a result, the specification 
(xey) > 
((p(x)reore®* => qn") 5 (p(x)"'" = qr") : 
is transformed into 
(x =t) A (y=t)) > 
(pj(xyrern™" = qv") > (px => qwenn) 
by parameterizing the predicate (x = y). Incorporating the two predicates (x = t) and (y =) 


into the appropriate procedure activations further transforms the specification into 


- 401 - 


([p dx) |(xat)]erves ==> {qt (y=tpprter) >. 
(Epi(x) | (xan) Pre" => Eg dy) Lysine) 
Since this is again simply specification swith qualifying -predicates on the procedure 
activations, the resulting solution specification contains condition: | 
count(ip(x) | (xat) ere) countt(ip(x): H(xae) Ph"), 


for the qualified gate [q(y) | (y=t)]?"*". 


The meaning of this soutien specification i is i following: For whatever value of t is 
equal t to parameter y of an activation of operation ng t the enter event for that activation 
passes through the gate Iq(y) Hiner, The condition for that gate is given nby _ 

_ count(lp(x) I (ret) Ft ~ countipts | (xeon, 


for this same value of t. Therefore, the “pate” {q(y) | (y=t)) aciiaily represents an entire set 


wee o 
> 


of gates, one for each value of t, which is to say each possible value of y. 


aw 
. An argument constraint predicate can always be parameterized into several predicates, 


each of which involves only the arguments to one procedure activation. In fact, many such 
ways of parameterizating a given predicate are possible. For reasons having to do with the 
implenientation that are discussed in chert 5, it is crarable that at most one of the new 
parameterized Po be a non-functional relation be between the activation eer 
and the parameterizing marlabie): and furthermore that this enema? non-functional 


relation apply to the arguments of the activation whose ¢ enter event is the offending event. 


This restriction can always be followed in practice. 
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Once a predicate has been parameterized, the resulting predicates then can be used to 
qualify the corresponding procedure activations. When all: predicates have been so 
incorporated, the specification consists entirely of. ordering clauses involving qualified 


procedure activations. This specification can. be analyzed iby the method presented 


"previously, resulting in a solution specification containing qualified gates. 


4.6 Justification of the derivation method | 


Both a problem specification language and the solution speciation structure have 
been defined formally in terms of a common basis, the le valiiy of histories. This means 
that the equivalence of a Epoue” specification and ene solution specification that is derived 
from it can be discussed in terms of the same set of histories being valid with i to 
each. Rather ‘than attempt a formal afoul of correctness for the derivation method, this 
section will present an informal justification of the method. The justification will rely, 
however, on the formal definitions given for validity of :histeries. The complete derivation 
algorithm is presented in Figure 45, with the individual steps mumbered for ease of 


reference throughout this section. 


In discussing the validity of histories with respect to both problem specification s and 
solution specification ss, we can refer to the definitions of the predicates Valid from Chapter 


2 and ValidSS from Chapter 3. They are repeated here: 
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Figure 4.5. Derivation of solution specification ss from problem specification s 


(1) Transform:s into a logically equivalent specification in which all argument constraint 
clauses are in the hypothesis of an implication and all ordering clauses are in the 
conclusion. 


(2) Parameterize each predicate on the arguments to more than one procedure activation 
into two or more predicates, each of which applies only to the arguments of a single 
activation. 


(3) Incorporate each argument constraint clause that applies to the arguments to a 
procedure activation by qualifying each appearance of that activation using the given 
clause as the qualifying predicate. The result is a transformed specification, to be denoted 
s'. Specification s’ consists entirely of ordering clauses on qualified events, except possibly 
for clauses involving invocation number variables only, appearing in the hypothesis of the 
implication. These clauses are ignored until step (8). 


(4) Construct the set Evexp(s’) consisting of all event expressions, including qualifying 
predicates, that appear in s’. The set of (possibly qualified) event classes associated with 
these event expressions represents the set of gates required in solution specification ss. 


(5) Construct all possible orderings of the elements of Evexp(s’), by generating all 
permutations of this set and then eliminating all those that are not possible. 


(6) Evaluate specification s’ for each ordering, denoting each ordering that evaluates s’ to 
TRUE as valid, and each that evaluates it to FALSE as invalid. 


(7) For each invalid ordering, find the longest matching prefix that it shares with some 
valid ordering, and identify the event following this prefix in the ordering as the offending 
event. If the offending event is not an enter event, then the specification is regarded as 
erroneous, and the algorithm terminates without being able to derive a_ solution 
specification. 


(8) For each enter gate (either qualified or unqualified) that applies to the offending event 
in at least one invalid ordering, characterize the state at each event to which the gate 
applies that appears in a valid ordering, and disjoin these characterizations to form Dy. 
Also, characterize the state at each offending event in an invalid ordering to which the gate 
apples, and disjoin these characterizations to form Dj. Any clauses in s’ constraining 
invocation number variables must be included in each state characterization. 


(9) For each enter gate for which step (8) is carried out, form the preliminary condition 
given by (D,, A ~(Dj)). Test whether this condition is satisfied at every event to which the 
gate applies that appears in a valid ordering. If so, then the preliminary condition is the 
condition for that gate in solution specification ss. If not, then proceed to step (10). 
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(10) Find an event that precedes. the: given: enter event in every valid ordering that. is 
excluded by the condition so far, and also in ty invalid baila: whose RNG event 
_ applies to the given a : tredaged 18 y 


(il) Characterize the state at each of these points, and form eo D,' and D;- of these 
characterizations wialeeous to those formed in ep ie 


(12) Test all valid orderings stil excluded to deuce which su the.term: n(Dy’ “A ~(D;)): 
If at least one such ordering does satisfy this term, disjoin the term to the current condition. - 


(13) If some orderings still donot ‘satisfy the condition, ther repeat steps (If) and €12) but 
using the characterizations both: forthe Onrrene state anda ‘the ahaa ‘event. : 


(J4) Repeat steps oy chvcnagh (13) until either all: valid cocersigs satisfy the condition or the 
weakening term: in step (12), or no previots everit cat ‘be found’ iti ‘step: (10).- If the former, 
then the condition formed by disjoining’ the pretminary conditiet’ anid “all the weakening 
terms from step (12) is correct and is attached to the gate in solution specification ss. If the 
latter, then the method: fails to derivé'a sohitién specification for problem specification s. 
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Valid({ J, s) = TRUE. 
Valid(add(h, e),s) = Valid(h,s) A . 
| V (ee, f) (ee € Evexp(s) ” f is an interpretation 
A Match(e, ee, f) > Sat(h, e, s, f) 


ValidSS({ J, ss) = TRUE _ 
ValidSS(add(h, <p, t, n, a>), ss) = WalidSS(h, ss) A 
V (ec, q) (<ec, q> € Gates(ss) A ec = <p,t> A q(a) © 
> SatSS(h, ss, <ec, q>) 


It is straightforward to compare these two definitions. They are both recursive formulas in 
which the basis case is the empty history [ ] and yields a value of TRUE. Also, both of the 
terms for the inductive case, which is add(h, e), are a conjunction of the given predicate 
applied to history h, and some term involving h and the last event e. Therefore, by 
recursion induction ([McC62]), the two definitions are equivalent if and only if these last 
terms are equivalent for all histories h and all events e = <p, t,n, a>. That is, it must be the 
case that 

V (ee, f) (ee € Evexp(s) ” fis an interpretation A Match(<p, t, n, a>, ee, f) 

> Sat(h, <p, t, " a>, s, f) | 
if and only if 
V (ec, q) (<ec, q> € Gates(ss) A ec = <p,t> A q(a) 
> ° SatSS(h, ss, <ec, q>). 

The first term requires predicate Sat to be true for all interpretations under which the event 
matches an expression in the specification. The second one states that for all gates in the 
solution specification “matched” by the event, predicate SatSS is true. These two terms must 


be equivalent for problem specification s and solution specification ss to be equivalent, in 
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the sense that they allow the exact same subset of possible object-histories to be valid. 


r 43 x Fo. i} Pa ar eas 
er Sole om ee ee Oe, or 
ren rs 2. ° ¥ eh thse th te 7 


Steps (1) through (3) of the-dérivation-method tihsferih the original specification s 


ty Shad 


into a new specification 8 eo justify” this ‘transformation, it must be shown that 
specifications s and s’ are Saiyan with hagas to the Validity: protieaierY alt which 


really means with a aig to the satisfaction predicate Sat. "Step , in ‘which all argument 


corp ooh fp pee Y 


‘constraint clauses are benaeti into the hypothesis of an Eaton simply involves 


"properties of first-order tégit:. Step (2),'tn which predientes involving algameries to-different 
-activations are partmetérined;is'also matheriatica Ip titwightorwatd.< 0 
To just sep oy et us tok at the transformation that it accomplishes. bidet start 
iL Sep 9ST Seeds | Ee 4ee 
from a specification of the form n Qe): > ro where Qa is a _quaktying predicate on some 


eat ae TeGee Ps £ aig Ae 


parameter vector v and 7 is 5 some specication invoiving oniy ordering Causes: According 
to the definition of Sat, 


Sath, e, wy) 2 a f) = pene e » Br), | > Sat(h, ©, 8, H). 


i230 Aon 3 


Furthermore, Qr must be some combination of arithmetic relations, which are invariant 
under the Sat predicate, since 


Sat(h, e, xP rel exP2 f) - » (Kexp)) = are 


{or 


This means that if the interpretation of v by : aise the iain predicate Q, then the 


ones emis mH | must be satisfied by event € ¢ and eet) h under pterpreaton f. 


If Qis not satisfied by the interpretation of y by f, then it does a mater whether 5 


Wagiecsbré BP “ibe 
satisfied under f since the overall speciation ne sated 1 regards es is eadly the 
renal hi € qualifying the appropriate procedure activation in 4 with predieat Qon v. ave 

DA ? SOHew Lee maby 


constraint represented ‘by 5 must be satisfied only if the qualifying predicate sell is 
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satisfied. Therefore, the transformation resuking frem step.(3) is consistent with preserving 
the meaning. of the specification; and..the-value-reusmned bythe Sat predicate is, the same 


when applied to the transformed specification s’ as to the original $&:5.:-: 


- The:next steps of the-algorithm construct the: possible orderings of the events for 
which the specification contains : expressions.. These ordesings -represent sub-sequences 
“within general histories. The-history:in-which eash ordering is embedded is assumed to. be | 
-otherwise valid . with respect ta. the: specifications, For: this reason, an-invalid..orderings 
(peel obs aohistory that is not: valid; while:aiwalicd erdering-maintaing the validity of the 
overall history. Therefore, a condition that . distiaguishes: the: valid .frem «the. invalid 


orderings is required to distinguish ail valid histories from invalid ones. 


. Step (4) of the derivation: algorithm consists of. the construction. of the set Evexp(s’) of 
“event expressions in the specification. This-can-be accomplished .by: using. the formal 
definition .of this set-in Chapter 2... The gates sequired .in the. salution, specification vare 
exactly the. gates associated. with this set.ef event expressions. If- the.specification. refers toa 
certain set of qualified event classes, the solution: specification.must contain. exactly. this.set of 
gates, since it is these classes of events that the:guardian must keep track. of in. order to 


implement the specified constraint. 


In.step (5) all possible orderings among the.elements: of Evexp(s) are constructed. 
. Each ordering actually represents a. sub-sequence. of a ‘history, containing. exactly. those 
events that are represented by the event expressiens-in:s\.under some interpretation. Since 


there is no restriction. at all-on. the quantification, the range. of. the interpretation is the 
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complete set of all interpretations: This means that: the ‘orderings: together constitute the 
‘entire class of possible subhistories that tonsist of the:events:represented:in the: specification 


under any interpretation: a a Sib pe Meat a UNE Bevetaeie ts yet 


An ordering is considered possible unless (a) there is some procedure activation whose 
enter event precedes, its request event, or whose exit event precedes its enter event; or (b) 
“there are two request events for the same‘ procedure such that the invocation number of the 
earlier one is greater than the invocation -wombersof the: later one-under.all interpretations. 
This step corresponds: 0s: the restriction of sth ‘domain: of Valid: to: histories satisfying 
‘predicate Possible, which-embodies these same restrictions. - 


ra ad 


In Step (6), ach: ordering is er i. ‘svahusie deccuncation sg. ‘resulting int a 
classification“of each ordering as either valid or invalid. Since the implicit interpretation by 
which the event expressions correspond to actual events-ts unrestricted, an ordering is valid 
only if, under any interpretation ‘whatsoever, each event iti it-satisfies the specification. An 

invalid ordering, on ‘the other hand, represeits a sub-history which: under some 
interpretation does not: satisfy the specification: “This is equivatent to the definition of the 
Vatid predicate; where for a history tobe valid; each event in it must satisfy the 


Specification for ald interpretations. 


The identification of the offending eVent for each invalid ordering instep (7) is 
straightforward. The validity of a history with respect fo a ‘specification ‘is defined: in terms 
of each successive event in the ‘history satisfying the ‘specification. Since the histery in 


which the ordering is ernbedded is valid: otherwise, the first’ event at which an invalid 
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ordering fails to match some valid ordering is the “offending” one. All events preceding 
this one must satisfy the specification according to the predicate Sat. The definition of the 
validity of a history with respect to a solution specification similarly is in terms of each 
event satisfying the solution specification conditions. This means that the offending event 
must be the point at which SatSS is first not satisfied, and therefore a condition must exist 


that is violated here. 


Step (8) requires the state to be characterized at each point representing either a valid 
or offending occurrence of an event of the given (qualified) event class. As described in 
Section 4.2, this characterization is made by existentially quantifying all variables and 
putting bounds on the counts of all gates involved in an ordering. The existential 
quantification of variables signifies the fact that the event expressions correspond to actual 
events under some unknown interpretation, and that every variable is therefore replaced by 
some unknown value. Each bound on the count of passages through a gate is either a 
lower or upper bound depending upon whether the event at that gate precedes or follows 
the point at which the characterization is made. If event x,,°"'*" precedes this point, then 


count(x®™®’) 


is presumed to be at least m, while if x,°"*" follows this point, then 
count(x®"'*") is presumed to be less than m. For an event involving a qualified activation, it 


is the count of the appropriately qualified event class that is bounded. 


This characterization is accurate because the scheduling at each gate is 

first-come-first-served. According to the solution specification structure, two activations 
e 

whose parameters satisfy the same set of qualifying predicates must pass through exactly the 


Same set of gates. Since the queue for each event class is FIFO, these activations must 
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proceed in first-come-first-served order. The rest of the state characterization. method 
simply involves ueoinoen ne existential quantification :on- ‘invocation number. values 
explicitly, and sfichuaings any explicit ‘constraints.on these: values that mer appear as clauses 


ins. 


The diSvacistiation that de: fen for sich, ondeting eoneiecta the most general 
expression possible of the current state following the occurrence of ‘ sis Hider 
‘corresponding to. the given.ordering. . Nothing is assumed: about: the: rest of the history 
except what can be deduced directly. from the-events: in-the ordering. itself. All unknown 
values in the formula. are -existentially quantified,-s0 the:fermula:simply states that there 
exist some values for which its body is:true. Fhat is.to say, there exists some interpretation 
causing a sub-history to:correspond to this ordering. Therefore, By, the-disjunction of the 
characterizations from all the valid orderings, represents: the: most. general expression of 
when an event in the. given qualified: class. can:‘validly occur.’ Using the formal semantic 
definitions of Sections 26 and 3.4, it is the most general characterization of.CurSt(h) for 
histories h which, when ‘fellowed. by::some event .¢-in the given class, satisfies the 
Specification s’ (by the definition of Sat) for any intespretation f.. Similarly, Dj;, the 
disjunction of the characterizations from. a} the invalid orderings, represents the most 
general expression of when such an event. cannet validly. occur..: This means that it is the 
most general characterization of CurSt(h) for histories that under some ine rpretait do not 


satisfy the specification when followed by an event i in n the class. 


a | 


The preliminary condition formed by (Dy A -(D;)) in step (9) represents an attempt to 
incorporate all histories with which an event of the given class satisfies the specification for 
all interpretations, and to rule out all those with which it does not. It is the conjunction of 
two terms, one ol which is the negation of D;, the expression of when the event tannet 
occur. For this reason, it is guaranteed to be a strong enough condition to exclude all 
invalid orderings, and therefore all histories that do not satisfy the Sat predicate for the 
specification. Therefore, no history that does not satisfy Sat will satisfy SatSS for the 
solution specification containing this condition for the given gate. Testing the condition 
against all valid orderings detetnines whether or not it is weak enough to allow all histories 
satisfying Sat. If so, then it is the correct condition, in that it causes exactly the correct set 
of histories to satisfy the SatSS predicate as well. If not, then there are some histories that 


satisfy Sat but would not satisfy SatSS if ss contains the given condition. 


Progressively weakening the condition allows more histories to satisfy SatSS. This 
weakening is accomplished by fepeating steps (10) through (13) using sitvious States, each 
time disjoining the resulting terms to the previous condition if they allow more valid 
orderings to satisfy the condition. The weakening term constructed from the first 
application of steps (II) and (12) involves only quantities in the previous state. If this is 
found in step (13) to be not sufficient, then repeating steps (Il) and (12) allows a term to be 
constructed that involves relations between quantities in the previous state and those in the 
current state. Since each weakening term is of the form (D,’ A ~“(Dj)), just as the 
preliminary condition is, no invalid orderings can become allowed as a result of this process. 


By choosing each time an event that precedes the given point in all remaining valid 
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. orderings. still not allowed by the ean: the weakening terms constructed have a good 
chance of including most if not: al-of. the remaining valid orderings.’ Therefore, steps (10) 
through (13).in practice rarely: need to be repeated midre than once ‘or twice: ‘Eventually; aif 
valid orderings. must be included, uniess' the ‘algorithm: fails due to ar’ inability to find a 
previous state in step’ {10} to use in constructing: new weakening terms. »$peditications for 


_ which this the algorithm fails are the subject-of the‘last section of this chapter. 
4.7 Failure of the derivation algorithm 


The structure of the solution specification # ‘flexible enough to express the solutions to 

a large class of synchronization problems. However; certaity Téeatdres do limit somewhat the 
range of synchronization constraints: that ‘tan be“expressed: The sokition specification 
structure is less general than ‘the ‘problem -specification dunguape, ~so that’ for some 
seer Micalions the derivation Aen is unable to construct equlvatent Sonton 
specifications: As noted in Section 4.2, this somes | is manifested oy dine Ing the 
offending event in an n ordering t to be ter han an enter event. Since this wore imply * 
condition ona request or r exit eae such a specication is + incompatible wih the solution 
+ art: yt ; 

speclicaiibn structure that cay places emeneo on n enter af gates. ihe algorithm therefore 
fails whenever an invalid sqroerang is found ial which ad offending event jis not an enter 


2 yes 
ar snes 


event. 
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The other manifestation. of incompatibility. with the . structure. of the solution 
specification is -an inability -to..fiad. sufficient previous states..at which terms can be. 
constructed to weaken cenditions. An. example of suck.an. incompatible. specification is the. 
“last-come-first-served" (LGFS) scheduling specification. of Example 6 in Section 2.7: 

(peer => pu = pi"), > (pent = pen eres 
When. the derivation algorithm. is.applied.to.this specificanion, the following preliminary 
condition: is first constructed. for. gate p°™'*’: 
- count(p'e*!) = coumt(pee’) «1 
This condition..is found not to be satisfied-by qne.of- the events. occurring in a valid 
ordering, however,-namely yn in the valid ordering. ; 
pm = pyre! iy hid = po. _ 
_ This must be distinguished fromthe offending event p,°""” in the, invalid. ordering 
, ; po => pn = pe > on. 
on the basis of previous state information. Since these padi differ ake in the identity 
of which of the two en events occurs first, and the identity | is not reflected in any 
siete on the parameters of the ae scivations c is obvious that the two cannot be 
. distinguished. In applying the algorithm, there are two Previous events at which possible 
weakening terms can be constructed: the most recent, vand next-to-most recent, a events. 
However, the state characterizations for the two orderings 2 are identical in each case, 
Resting in potential weakening terms that are realy F FALSE and thus not useful. Asa 


result, the derivation ends in failure, s since no other possible weakening t terms are » available. 


ik ees 


- Il 


', The reason for the failure-of the algorithm: on this specifieation is that the property 
specified requires: two different activations to be distinguished; not‘on the basis of their 
parameters, but simply ‘by their identity. A: SehRieh specification “coidition for this 
. constraint would: have-to depend: on not only the number oF previous events, which would 
involve the current synchronization state, or even thé order of these events, since this 
information can always be obtained froth previous tise informition; as explained in'Seetion 
3.3. Instead, the constraint relies on distinguishing the: dééarity’ of two different activations. 
However, since there is no parameter-retinted “property ‘by Which to distinguish the two 
activations, the: structure of the: solution specification requirés‘that:-the’ activations pass 
through the same gate or set of gates for the pe" event class in FIFO order. The 
requirement in the specification of non-FIFO scheduling“is in direct contradiction with the 
solution specification’ structure. This is‘ why the’ derivation’ algorithny cannot possibly | 


succeed in deriving a solution specification for this specification. 


Synchronization: constraints such as ne ECS specication that rely on ne pRonelty of 
particular events are rather pouia in practice, and helt Renal mae with ane solution 
Spreiicalion =) structure is not rey distressing, A second kind =. incompatibility, though, 
is demonstrated by a very comnonty desired property, the  firs-come-fire-served (FCFS) 
specification of Example 5 in Section 2.7: 

(pour => wen ° (Pi enter = qj , | 
This specification, somewhat fia suas is also one for which the derivation hal a solution 
Specification fails. The reason is that this ‘cacleradiistion oes cannot be iniplemented 


using one queue for each event class and one entry condition for each queue. An 


- HS - 


implementation using the serializer construct appears:in [Hew77} for a FCFS scheduling 
‘property on two operations “read” and “write”, but this relies on the two operations sharing 
the same: queue, though with different entry conditions. A monitor implefnentation was 
devised in an unpublished note [Bro76], but here again the two operations shared a single 


queue, with one of the operations using a second-auxiliary queue as well. 


une reason that a solution specication aust be constructed for this preven is that 
it re be a to veh information at a nae State jae g a arbitrarily far back in 
the history. The solution soecinication structure allows states to be saved at the most aad 
event at a gate, arid by extension, at the mext-to-mest récent, etc. However, the FCFS 
constraint requires that each enter event! use information: from: the point im the history: at 
which the corresponding request everit took place, which may be arbitrarily far: back. That 
is, the condition for enter: events: by different’ processes must involve information saved at 
previous states individually applicable to each process: Specifically; tet 
siseaed) siivate @ prewesty 

_ be a quantity that for any particular activation of operation p represents the value of 
count(ec) saved at-its request event. Then the:conditions on gates p°!* and gener could be 
expressed ‘as: 

prrler.  [count(q’*") private @ pete" }-« count(q?"'*) 

q*"*: [ceunt(p’*"*") private @ q/e*!] = count(p'*") 
That is, there must be as many q°"*" events at the time of a p°"'*’ event as there were 


request 


q events when the given activation of p was requested. 
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The use of this kind of information that is “private” to each process appears in 
[Owi76] to specify solutions to synchronization problems. Interestingly, the LCES property 
can also be-expressed with the use of private information. The. condition. on; gate pore 
becomes: 

(count(p'°™").- feount(p"*"") private-e pet**'D = 
(count(p*"'"’) - ee private ® oe 


' In other words, all be for P since this activation of P was requested must t first be 


fulfilled. 


" The solution specification can.only save states ata “fixed” distance back from the 
current state, here “fixed” is: relative to the. nuraber of, events at.a gate. Information 
| privately saved by each process must be saved at. states arbitrarily far back in the history. 

Without such privately. saved. information.: the solution: specification. structure is unable to 
express certain properties, including the rather straightforward FCFS property. This must 
be considered a weakness of the solution specification and:therefore of the synthesis method. 
However, it is nevertheless true that: most. specifications are compatible with. the solution 
Specification structure, : so that: the. derivation. algorithm dees succeed in constructing 
equivalent solution specifications in most cases. The next chapter describes the. ere 


the synthesis for these cases, the amplementation af the: solution: specification ini actual code. 
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Chapter 5. 


The Source Language Tiplementation 


5.1 Introduction 


“The derivation of an sacivalent solution specication from 7 problem specification, 
using the algorithm presented in Chapter 4, constitutes the major conceptual task ‘involved 
‘in “synthesizing actual syechronization code. The derived ‘solution specification iS a 
procedural representation of the same ordering ¢ constraint that is expréieed i pone pieced uray 
‘by the problem specification. The final — in the ayia implementing the solution 
specification in terms of an appropriates source ce language synchronization mechanism. ‘The 
translation from solution specification to source ce language is the subject of this chapter, and 


while relatively straightforward, it is not completely obvious for all cases. 


The. structure of the solution specification is general enough for it to be translated into 
any one of a wide range of source language synchronization. mechanisms. For purposes of 
explaining and _ illustrating . the .translation. technique, the - monitor construct of Hoare 
([H0a74}) will be used throughout. the thesis. An implementation: using an alternative 

high-level synchronization. enéchianisen such .as conditional critical. regions ([Bri72)}..or 
serializers ((Hew77]) would be quite similar... If a Jower-level. mechanism such .as semaphores 
((Dij68}) is preferable, then an, algorithm gives.in [Hoa?4).can be used to further translate 


the monitor implementation given here into semaphore code. 
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A fundamental assumption of the medel-used here is that all synchronization for a 
data object takes place through a single centralized mechanism associated with that object. 
This does not cause any problems with an implementation in terms of monitors, or any of 
the other constructs cited above. However, it does make the solution ‘specifi¢ation structure 
somewhat incompatible with situations in man a on oot is distributed throughout 
some decentralized Sytem: and wee it is petltae for the synchronization control piniarly 
to be distributed. The Structure of the. solution specification Cor | not give much ‘aid in 
deciding how to perform ti the messape: parsing required in a aeioues haa to implement 
the SCI ONKEA ON. constraint. ‘For ‘centallied “synchronization mechanisms auch as 
Monitors, though, the sopremenncon? is not too circa, 3 as 5 will be demonstrated ¢ once the 


monitor construct itself has cen antroenced in the next section. 


ares othe i 


5.2 Monitors 


The monitor is a synchronization mechanism that was first described by Brinch 
‘Hansen in [Bri73) and defined more formally by Hoare in Toa) It prew out of the 
“secretary” concept proposed by Dijkstra in [Dij72b): A monitor is'an extension of the class 
construct of Simula [Dah72], with one important difference. A’ monitor; like a Simula class, 
conn of some focal data and a collection of procedures for mahiputating ‘that data. The 
rhajor difference is that executions of the procedutes of a monitot are mutually exclusive, in 
order ta protect the integrity of the local data. Processes: attempting Concurrent executions 
of a monitor’s procedures must wait to'gain exclusive access to:the monitor. This waiting is 
defined by “Hoare to be fair, and can be assumed to follow a first-come-first-served 


discipline. 
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Monitors also contain features for explicit process synchronization. As defined by 
Hoare, this takes the form of a condition data type, which represents a FIFO queue of 
waiting processes. Two operations are defined on a condition for queuing and dequeuing 
processes: "wait", which causes the process executing the operation to enter the queue; and 
"signal", which dequeues the process at the head of the queue, if any. Both operations cause 
the process executing the operation to relinquish possession of the monitor. A process on a 
queue that is dequeued via a “signal” operation by some other process regains possession of 
the monitor. It resumes execution of the monitor procedure it was executing at the point 
immediately following the “wait” operation that it performed. An additional operation 


“queue” returns a boolean value, indicating whether any processes are on the queue: 


The notation used here will be based on the language CLU [Lis76] rather than the 
Simula-based notation introduced by Hoare. Thus, a “wait” operation on condition variable 
c is written 

condition$wait(c), 
rather than 
c.wait; 


as in (Hoa74). 


Hoare advocates associating informally with each condition variable a boolean 
predicate on the local data of the monitor. This predicate indicates what condition on the 
monitor state a process on the queue is awaiting. Making this association aids in proving 
properties of monitors. As indicated in the next section, this association makes condition 


variables suitable for representing the entry conditions in the solution specification being 
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implemented, 


5.3 The basic monitor implementation 


A comparison of moniters with the solution : specification structure discussed in 
Chapter 3 reveals a close correspondence. between features of-one:and ‘the other. The focal 
data of a monitor: is sufficient for representing: the state:information required in a solution 
Specification, since this state information can be represented bya collection of integer-valued 
quantities. A condition variable in a monitor is a FIFO queue of waiting processes, and as 
advocated by Hoare, has associated with it:informatly a boolean: predicate on the monitor 
data. These are exactly the features required for conditions associated with enter gates in a 
solution Despeotication: Passage through a set of gates associated with a sptven. event class 

must be indivisible and produce a state change in the aysem Monitor procedures are ideal 
fe implementing gates, in that they manipulate the local data of the monitor, and because 
the enforced mutual exclusion on their executions makes. them indivisible operations. 
Monitor procedures can take parameters, which is important since the behavior of gates 


sometimes depends on the arguments to the associated procedure activation. 


It should be emphasized here that the monitor is being used to implement only the 
synchronization code, not the abstract data Lae asa whole. The monitor was originally 
conceived in [Hoa74] to imap tenia a shared data abstraction itself. Criticism of the monitor 
construct has appeared: in some recent technical literature Ae Hew77], Diad77} lam77). 
The basis of this criticism has been that the: use of monitors to implement abstract data 


types leads to such problems as reduced concurrency, lack of modularity, and a potential for 
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deadlock through hierarchical monitor calling. As used here, however, the monitor is 
employed within a data abstraction, for the sole purpose of implementing the 
synchronization code required by the operations of the abstraction. The monitor procedures 
are kept small in size, so that their use does not significantly affect the degree of 
concurrency possible. Modularity is enhanced by implementing the synchronization code 
separately from the abstract data operations. Since lower-level abstractions are called from 
the bodies of the operations, not from the synchronization code, the problem of hierarchical 
use of monitors is avoided. (See [Blo78] for the advocacy of a similar discipline in the use 


of monitors.) 


_The monitor for a data type contains three procedures for each operation p of the 
type. These procedures represent the three event classes associated with p, and are named 
p_request, p_enter, and p_exit. It is necessary that the procedures of the derived monitor be 
called at the proper points within the data abstraction operations, in order to ensure that 
the monitor is used properly and the synchronization constraint is embodied in the data 
abstraction. The form that operation p must take is illustrated below in Figure 51. The 
identifier "m" is the name of the constructed monitor, and v is the vector of parameters to 


operation p. This vector of parameters actually must be passed to the monitor procedures 


only for implementations involving qualified gates, as explained in Section 5.5. 


The monitor implementation of a “basic” solution specification that involves neither 
previous state information nor qualified gates is straightforward. Recall that the abstract 


program for an activation of operation p of the data abstraction in such cases is given by: 
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Figure 5.1. Monitor calls within operation p- 
papre | 

call m. - prequesty): 

call m.p_enterty) . 


| (body of p) 


call mp: exitty) 
end p; 


prowent, increment count(p ee) by 1 


poo’: wait,unul entry. cendit 
. then increment count(p"™*’) by 1 


execute body of operation p 


p*": increment count(p**") by | 
_ For each quantity of the form count(ec) that appears in one or more pe conditions 
in the solution specication, rere isa corresponding variable of type integer in the monitor. 


This variable is initialized to 0, and is incremented by 1 in the procedure that t represents 


| event ciass : ec. 


An anette implementation could employ. instead a separate variable for. each 
quantity of the form (count(ec)) - count(era)), since a condition, almost.always concerns the 
difference neue une SOUNK....T he inplameptation. chagen, here, is, somewhat. simpler, for 
puiperss of explanation. It does, however, incur as possibility of integer wee, since 
each variable is constantly increasing over time. Ainough techniques can b be used to ‘avoid 


overflow by dynamically extending the precision ‘of integers, the “akernative might be 


preferable in practice. . 
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For each enter gate with an entry condition.in the solution specification, the monitor 
contains. a. condition varjable. .The boolean _ predicate infogmally associated with this 
variable is. exactly. the.same.as the entry candition, with each. quantity of the form count(ec) 
replaced by the corresponding variable. Let the condition variable corresponding to gate 


p*"'*’ be pentry, and denote the predicate associated with itas C,. Then the first statement 


P 
- in procedure p_enter is 
— "if - Cy) then condition$wait(pentry), end; : 
Whenever control of the monitor is relinquished, it is necessary to check the predicates 
associated with all condition variables on which processes are queued. If one or more of 
"these predicates are satisfied, then a “signal” operation ‘is’ performed on one of the 
conditions. The cofidition’t0, be signalled me be chose ina fair manner, so that no 
process starves because the condition on which it is queued is never chosen for signalling. 
This can be accomplished by using a variation of Dijkstra’s "guarded commands” {Dij75) to 
implement a new kind of statement called a “choice” statement. Changing Dijkstra’s 
notation so as to distinguish chotce statements from ordinary ff statements, a choice 
statement looks like: 


choose 
By: Sp 
Bo: S93 


end; 


where the number of guarded commands n 2 1. The meaning of this statement is the 


following: The “guards* B; are simply boolean expréssions. If one or more of these guards 
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are true, then one of the true guards Bi ‘is (non-determindtely) ‘selected and the 


J 
statement and Dijkstra’s version. The mettiod for makitig the’ selection’ between severa¥ true 


corresponditig staternent s, ‘is executed: There are two important differences between this 


guards is unspecified but must be fair. Also, if none of the guards is true, then’ the 
statement is simply skipped. | 


If, the condition variables in the monitor are pentry, gentry, etc. with corresponding 


+ 


boolean predicates C etc., then the following choice statement must appear at the end 


p Sq 
of every monitor procedure: 
choose ° 
condition$queue(pentry) A C,: condition$signaKpentry), 
condition$queue(qentry) A Cg: condition§signaKgentry), 


end; 
This ensures that whenever one or more waiting processes can be dequeued, due to the 
satisfaction of the predicates on which they are waiting, one of them . will in fact be 
dequeued. The fact that the predicates in the guards include the conjunct of the form 
condition$queue(pentry) ensures that the condition that is signalled does in fact have a 
| waiting process. As long as the icon is made fairly, the monitor will be a faithful 


implementation of the solution specification. 


A property of the monitor construct that is used here is that a process that is dequeued 
from a condition variable via a “signal” operation gains possession of thie morritor ahead of 
any process that is attempting to.call a monitor procedure. This ensures that a process that 


has been waiting for an entry. condition to become satisfied is allowed to proceed as soon as 
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the condition is in fact satisfied, and is not overtaken by a later-arriving process. This 
property is necessary for the faithful implementation of the FIFO scheduling that is part of 


the solution specification structure. 


In practice, it is often possible to optimize the signalling statement by eliminating some 
of the options in the choice statement. The basis for such eliminations is that the 
corresponding guards cannot possibly be satisfied at the given point in the monitor, due to 
the rest of the monitor code. In fact, for many simple examples, at most one guard in the 
choose statement can ever be true at any given point. However, in general the analysis 
required to perform this optimization is difficult. Rather than becoming involved in the 
details of when a given option can or cannot be eliminated, the simple-minded 
implementation of always testing all conditions will be used here. (In practice, it might be 
simpler to make a separate procedure internal to the monitor for this signalling code. Each 


of the regular monitor procedures could then call on this internal procedure.) 


An optimization that can be made easily is the elimination of unnecessary monitor 
procedures. If no reference is ever made to the quantity count(p'****') or count(p™"), then 


the body of the corresponding procedure is empty. The procedure itself, along with the call 


to it within the data abstraction operation p, then can be eliminated. Similarly, if there is 


enter enter) 
, 


no entry condition associated with gate p°”*’, and no reference to the quantity count(p 


then procedure p_enter can be eliminated. 
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_- AS a concrete example of a monitor i 


ation, consider, the . following 
_ Specification: ae 27 ae pistes Ssbue ox 
(per => geri) > (peer =a.gi)) A 
(grr = ps) > « exit Pj centery) 

There are two clauses, a one giving operation P priority over operation q. the other excluding 
‘fnew activations of operation p during active executions of of operation q. “The solution 
‘specification for this ‘example consists of the conditions sea Recoil - | - 
For gate qt count(p"*™*") = count(p"™"), } 

For gate poner. countigr™™) = = ; count(q***) | 

The monitor implementation of this solution specification contains. four integer 
variables, representing count(p"*™**), countip"™*"), countig’™*").and countiq™). These 
variables are named pr, pn, qn, and gx, respectively. Each. yariable must.be initialized te.0, 
and incremented. by | in the corresponding .manitor. procedure... There. are two.condition 
variables, pentry and gentry, for the entry conditions on gates e and a The 
predicates associated with these condition variables are the analogues in terms of monitor 
variables to the solution specification entry conditions: (pr = pn) for gentry “aiid (qn - wo 
for ‘pentry. The monitor “ex” ‘that is obtained for "this example ag appears in Figure 52. ‘The 

monitor procedures p_exit and q se have been eliminated i as s unnecessary. Operation p 
of the data abstraction must call monitor procedure ex. parequs and xp. enter a that 
' order) before executing its body, while. operation q must ‘all procedure exes enter - before 


executing its body, and ex.q_exit afterwards. 
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Figure 5.2. Monitor for example 
ex = monitor; 
Pr, pn, qn, qx: integer; 
pentry, gentry: condition; 


p_request = procedure; 
pri=prel; 
choose 
condition¢queue(pentry) A qn » = QX: condition$signaKpentry); 
condition$queue(gentry) \ pr = pn: conditionSsignalgentry), 
end; 
end p_request; _ 


pienter = procedure; 
if qn # qx then aeene tenn) end; 
pn := pn.+ kh. 
choose 
condition$queue(pentry)  .qn.=.qx: condition$signal(pentry); 
condition$queue(gentry) A pr = pn: enalconenaneneesy} 
end; eh 
end p_enter; 


q_enter = procedure, | 
if pr # pn then conditiontwaitgentry end; 
qn := qn +1; ies 
choose 
_ condition$queue(pentry) A, qn-= qx: eee tiene 
condition$queue(qentry) A pr = pn: caine eed 
end; 
end q_enter; 


q_exit = procedure, 
qx := qx + I; 
choose ieee t 
condition$queue(pentry) + A qn = qx: condition$signaKpentry), 
condition$¢queue(qentry) A pr = pn: condition$signal(qentry); 
end; 
end q_exit; 


pr, pn, qn, qx := 0, 0, 0, 0; 
end ex; 
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5.4 Previous state information 


When a solution specification contains references to quarititiés ‘ride onty ‘in the current 
state but also in previous states, these e quantities must be maintained ‘in the tmionitor ina 


different manner. Speen: a ‘separate monitor varia & me hee for daeh quantity of 


arait 


current value of the variable representing teuiitee) in the monitor procilicie corresponding 
to gate g. That is, it is set in the procedure Tepresenting. gate’ by ‘aisigning ‘to it the 
current value of the variable representing count(ec). It can be’ use in ‘the boolean 
predicates associated’ with: condition Vartables in the same way iia ‘variable that represents 


a quantity in the current state. 


e 


Consider example 7 from Chaps. 2, a Es aeons le ee. heseiipel pairing’: 


(a; enter => bry # (ct = ar 


The derivation. LSP thie sdlution sc pinilmacer Tor this bk i eWay tharted in Section 4.2. The 


SAAS TO: 


overall solution specification is: 


For gate a°"'*: 


(count(b*"'") 2 2 count(deme) v ( tome) e ae < fomunieye acter 
For gate pester. Te ee A ietietale aupdneniie - 

(count(a®™*") 2 count(c*™*")) v ([count(b*™*) @ co") < feountia") « on) 
For gate comer. , 


(count(d*™*’) > count(b*™*")) v ([count(c*™*") e b*™*"} < [count(a®*”) e b*"*")) 


For gate d*"*": 
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(count(c?™®") > count(a®™*")) v ([count(d®"'*") @ a®"*’]) < [count(b®™*”) @ ae”e’}) 


Since the entry waacigone do not involve any request or exit gates, only four procedures are 
needed in the monitor, one for each enter event clas Each of the operations a, b, c, and d 
must call the appropriate monitor procedure prior to executing its body. The variables an, 
bn. cn, and dn can be used to represent the current counts of the four enter event classes. 
In addition, eight other variables are needed to save the values of counts in previous states. 
Variable amrd, for example, represents the count of gate aenter saved at the most recent 
deer event. This variable is set in monitor procedure d_enter to the value of an, which 
represents the current value of count(a®"*’). Similarly, variable cmrd represents the count 
of gate c°"'* saved at the most recent d°™*’ event. The predicate for the condition variable 
aentry on which procedure a_enter performs a wait operation is: 
bn 2 dn v amrd < cmrd. 
The predicates for the other condition variables bentry, centry, and dentry are analogous. 


The complete monitor appears in Figure 5.3. 
5.5 Qualified gates 


The remaining issue to be handled is the implementation of qualified gates, which 
arise in a solution specification from the presence in the problem specification of predicates 
on the arguments to procedure activations. Recall from Chapter 3 the abstract program for 


an activation of operation p in a situation involving qualified gates: 
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Figuce.5.3, Monitor for operation pairing example, © cpu: 


pairs = monitor, 
~amrd, pic “bmrc, dean iateaee _ 
., ,amrb, cmrb, bmra, drara: integer; 
aentry, bentry, centry, dentry: condition; 


on 


a _enter = procedure; “ 
if (bn < dn. amrd 2 cmrd) then conditian$wait(aentry); nd;. 
an:=an+l,; 
_ bmra := bp; 
dmra := dn; _ 
choose gre, ; 
condition¢queue(aentry) A (bn 2dnv amrd < Cred condition$signaKaentry); 
-, condition$queue{bentry) A fan 2.cn V.brorc,< danec):.cauditipn§signal{bentry), ° - 
condition$queue(centry) A (dn 2 bn v cmrb < amrb): condition$signaKcentry); 
conditton$queue(dentry) A (cn 2-anw-dawa « brea} eend{ddon$tignakdentry).. 
end; 
end a_enter; eis 
b_enter = procedure, 
if (an <cn A bmre 2 dmre) then nconitionbwai(vntry ‘end; 
bn := bn + |; aise 
amrb := an; 
_ cmrb = cn; 
choose : 
condition$queue(aentry) A (bn 2 dn V.amrd. < cmrd): condition§signaKaentry);. : 
condition$queue(bentry) A (an 2 cn V bmre < dmrc): condition$signaKbentry); 
condition¢queue(centry) A (dn 2 bn v cmrb < amrb): condition$signaKcentry); 
condition#queue(dentry) A (cn 2 an V dmra < bmray, oaditionfpignakdentry) © 
ona = 
end b_enter; 


center = - procedure; 
if (dn < bn A corb 2 amrb) then conditian§wait(centry), end; 
cn := cn +1; E 
bmrc := bn; 
dmrc := dn; 
choose Be 
condition¢queue(aentry) A \ (bn > ‘da v and: < amr). condition$signaKaentry); 
condition$queue(bentry) A (an 2 cn Vv bmre < dmrc): condition$signal(bentry), 
condition$queue(centry) A (dn 2 bn v cmrb < amrb): condition$signa\centry), 
condition$queue(dentry) A (cn 2 an V dmra < bmra): condition$signaKdentry); 
end; 
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end c_enter; 


d_enter = procedure; 
if (cn < an A dmra 2 bmra) then condition$wait(dentry), end; 


dn := dn +1; : 
amrd :=an; 

cmrd := cn; 

choose 


condition$queue(aentry) A (bn 2 dn Vv amrd < cmrd): conditiontsigna\aentry), 
condition$queue(bentry) A (an 2 cn Vv bmrc < dmrc): conditiontsignal(bentry); 
condition¢queue(centry) A (dn 2 bn v cmrb < amrb): condition$signal(centry), 
condition$queue(dentry) A (cn 2 an V dmra < bmra): condition$signaK(dentry); 
end; 
end d_enter; 


an, bn, cn, dn := 0, 0, 0, 0; 

amrd, cmrd, bmrc, dmrc := 0, 0, 0, 0; 

amrb, cmrb, bmra, dmra := 0, 0, 0, 0; 
end pairs; 


gees 
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. mvrequest, 
Pp : 


in parallel for all gates g in event class p'°oves', 
if v satisfies the qualifying predicate of g, 
then increment count(g) by 1 
p°"'*': in parallel for all gates g in event class p°"', 


if v satisfies the qualifying predicate of g, 
then wait until the entry condition of g is satisfied, 
and then increment count(g) by | 


execute body of operation p 


Pp 


ex, in parallel for all gates g in event class p™™", 


if v satisfies the qualifying predicate of g, 
then increment count(p*) by I | 
How this abstract program is implemented in a monitor depends to some extent upon the 
nature of the qualifying predicates. In all cases, though, it is necessary that each of the 
monitor procedures -p_request, p_enter, and p_exit take the same vector of arguments as the 
data abstraction operation p itself does. This allows the monitor, procedures to test the 
qualifying predicates on the arguments, thereby determining which ose apap to an 
Operation activation. Each monitor procedure implements the entire set of gates for the 


given event class. 


Qualified request and exit gates are easier to implement than qualified enter gates. 
Since these gates consist only of incrementing integer variables, it is merely necessary to test 
the qualifying . predicate before incrementing. The simplest case involves a predicate 
concerning only the arguments to the associated data type operation. A qualified count, like 
an unadalified one, is represented by an integer variable initialized to 0. The update to this 


variable is preceded by a test of the qualifying condition, and is only made if the condition 
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is true. For example, let the qualifying predicate be Q(v), i.e. the quantity to be updated is 
something like count([p(v) | Qhv)}*"*). If x is the monitor variable representing this 
qualified count, then the update statement in procedure p_exit is 


if Q{v) then x:=x+l; end; 


There may be more than one qualified gate for an event class, in which case a 
separate state variable is required for each gate. The update of each state variable x; must 
be preceded by a test of its corresponding condition Q;. Because more than one of these 
conditions may be simultaneously satisfied, it is important that the tests be made in a series 
of statements of the form 

if Qiv) then x; := x; + | end, 
rather than in one statement such as 


if Qy(v) then xp = xy +1 
elseif Qolv) then Xo := Xp +1 
elseif ... end, 


that could only increment one variable at most. 


A qualifying predicate may be parameterized, and so involve not only the arguments 
to the associated operation, but also a parameterizing variable t. (There actually may be 
several parameterizing variables ti but they can be combined into one composite variable t 
= <t, .. {,>-) For each possible value of t there is conceptually a separate gate, which means 
there must be a separate quantity in ‘the State. For example, suppose that a solution 
spetication contains a quantity of the form count([p(v) | Q{v, ern"), If the parameterizing 


variable t were of type integer and could only take values from a restricted range, say | to 
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100, then this quantity could be implemented by-an array with that subscript range. The 
n-th element in:the array-would represent the quantity count([p(v) |} Qty, Wy*"). 


In general, of course, variable t is not becca i an » integer and it is impossible to 


a a 
< 


know ahead of time all possible values for t. The same ise can be used in the 
implementatien, though, by. employing an abstraction: that captutes:this same effect. The 


parameterized type “counts(¥]",.where T represents: the type-of:f,- contains counts for all 


possible values of t, atleast conceptually. These counte.are:git:set to-O!imitially when a new ~ 


object. of type -¢ounts{T] is created, and the-count corresponding tena: particular value.ty is” 


incremented by the operation “incr” with tp as argument. 


In the actual implementation of the type countsiT 1 the count for any re value 


a 


of t is created and added to the object of type sal only a as at becomes needed: The 


implementation of this type in a Preuss with “dynamic arE “wah as CLU is 


Straightforward. However, the dynamic creation of counts-.as they:are needed is an 


ius be edgi sc) Agee tet eth dee. 
' implementation detail; users of the type can. ignote this arid use thé abstract conception of 


all counts that are needed being created as part of the object initially. 


“For the purpose of translating a solution specification into a monitor, each state 


variable répresentiig’a qualified count whose predicate is patameterized-by variable t' must — 


be implemented by: an object of type oounTT t ‘A “Create” operation for this object is 


required in the initialization code of the monitor. The’ “qualifying predicate must take the 


form of a functional elation: between ‘variable t dnd’ the’ arguments of the ‘procedure 


activation, ie. the qualified quantity must be’of the form count(fp(v) | t = f(v)I*), It is 


RX 
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always possible to parameterize a predicate so that at most one activation is non-functionally 
related to the parameterizing variable t.. This activation should be chosen to be the one for 
whose enter event the condition is derived. This means that only one value of t can apply 
to any given Svat and so only one count needs to be incremented. Incrementing the 
proper count is accomplished by the statement 

‘counts{T]8incr(cou, f(v)) 


where T is the type of t and cou refers to the object of type counts[T]. 


There must also be an operation “get”, analogous to the “fetch” operation on arrays, by 
which the count for any particular value of t can be retrieved. This operation is used 
within the predicates for conditions associated with parameterized enter gates, as explained 
below. The quantity 

count([p(v) | (t = f(v))P"*) 
in a solution specification entry condition is implemented by the operation call 
countsIT I$get(pexitcounts, f(v)), | 


where the object referred to by variable pexitcounts represents count([p(v) | (t = f(v))]**"). 


Qualified enter gates are more complicated to implement than other types of gates. 
Not only must a quantity of the form count([p(v) | Q(v))}?"*") be updated, but first some 
entry condition must be satisfied, which means that waiting must be implemented. The 
simplest case is when there is a single qualified gate for the event class, and where the 
qualifying predicate is only on the parameters to operation p. Then there is a single 
_ condition variable “cond”, just as for an unqualified enter gate. The wait operation on 


“cond” is preceded by a test of the qualifying predicate Q{v) as well as the associated 
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predicate C: 


if Qlv) A (> C) then condition$wait(cond), end; 


When an enter event class contains more than one gate, each with a different 
qualifying predicate and entry condition, then there must be a separate condition variable 
for each possible subset of gates whose qualifying predicates may be satisfied by an 
activation. The boolean predicate associated with each condition variable consists of the 
conjunction of the entry conditions on all gates in the subset of gates to which the condition 
variable corresponds. An unqualified gate, of course, applies to every activation, so if there 
is an unqualified gate, its condition must be part of every predicate. In cases where two 
qualifying predicates are contradictory, or where one implies another, some subsets of gates 


will be impossible and can be eliminated from consideration. 


For example, assume a solution specification contains the following entry conditions: 

For gate poner count(a®™*") = count(b*'*’) 

For gate [p(v) | Qv)}er.. count(a’®v**') = count(a®"*’) 

For gate [p(v) | Qav)jerter; count(b®*") = count(ce™e’) 
Assuming that predicates QI and Q2 are not contradictory, and that neither one implies the 
other, then there must be four separate condition variables. These must cover the 
activations satisfying neither QI nor Q2, both QI and Q2, and either one but not the other. 
The unqualified gate applies to all four cases, of course. Let variables ar, an, bn, bx, and cn 
represent the quantities count(a"®**!)  count(a®™*"), count(b*"*’), count(b®"), and 
count(c*"®'), respectively. The predicates associated with the condition variables are then 


c0O: an=bn 
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cl: an=bn A ar=an 
c2: an=bn A bx =cn 
c3: an=bn A ar=an A bx «cn 
The code involving these variables at the beginning of monitor procedure p_enter(v) is: 


if QAv) A Qi(v) A (an # bn v ar #an V bx * cn) 

then condition$¢wait(c3), 

elseif Q2Av) A (~ QKv)) A (an # bn v_ bx # cn) 
then condition¢wait(c2), 

elseif (~ Q2v)) A QKv) A (an # bn v ar # an) 
then condition$wait(cl), 

elseif (an # bn) 
then condition$wait(c0), end; 


It QI and Q2 are contradictory, then condition c3 may be eliminated, while if one implies 


the other, then either cl or c2 is not needed. 


A qualifying predicate on an enter gate that involves a parameterizing variable t 
presents the most difficult implementation problem. Since this construct actually represents 
a separate gate for each possible value of t, a separate condition variable is needed for each 
possible value of variable t. To implement this, what is required is something like an array 
of conditions, but with a dynamic range, so that new conditions can be created and added to 


it. 


The implementation uses a type called “conditions[T]". An object of this type contains 
an object of type condition for each value in its domain. The initial domain of the object 
returned by the “create” operation is empty. In general, the domain consists of the set of 


values of t that have been explicitly added by means of the “add” operation. The “add” 
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Operation creates a new condition only if one does not yet exist for the given-vahie of t, so 
that subsequent calls on "add" with the same value of t have no effect. The predicate 
associated with each condition is parameterized by the associated value of t, and so is of the 
form Cp(t). Notice that while the exact set of conditions is determined dynamically by the 
"add" operations, the form of the predicate for each one is fixed, except for the Value of the 
parameterizing variable t. nani ga as _ 


The first step in implementing parameterized enter gates ig t2.corhine all the enter 
gates in the event class into all possible combinations:aésatdafinble qualifying predicates. If 
there is an unqualified gate for the event class, then its entry condition’ becomes a conjunct 
of the Parameterized - condition £ ptt). When ‘there ee "individual. (nor parameterized) 
qualified gates, then the same analysis as to possible subsets of satisfied gates must be made " 
as was discussed above and illustrated by the example involving predicates Q; and Qo. As 
before, there must be a condition repretentirig each possible ‘subset of gates through which a 
given’ procedure activation’ may ‘pass. © Sifce tide’ ir pra edna ‘gates, ‘this requires a 
separate object of type" conditiods{T] ‘for “eadh’ combination of ‘gates including a 
paraiieterized” gate. “Thé remaining discussion focuses’ on a single object of type 


eg his 


conditions{T], bit notés howto generalize to casés involWitig many such objects. _ 


Given an enter gate qualified by some predicate parameterized by variable t, the 
_ relatton R: between’ variable t-and parameter vector v of thé operation being qualified may 
or may not’be a fonction. If it is a function, the qualifying predicate takes the form t = f(v). 
The condition on which to- possibly wait is then found by callirig the “get” operation on the 


object ‘tonds of type conditions{T] with argument f(v). ‘The “pet operation, similar to the | 
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“get” operation on counts(T], retrieves the condition corresponding to the value of its second 
argument. The code for waiting in the monitor “enter” procedure is therefore: 
if (- Colflv))) then condition$wait(conditions[T #get(conds, f(v))); end; 
To guarantee that the object conds does in fact contain a condition for the associated value 
of t, the statement 
conditions{T Badd(conds, f(v)); 

is used to add the appropriate condition to the set of conditions in object conds if it is not 
already there. This operation must sicede the waiting statement, a fact that can be 


ensured by placing it at the beginning of the “enter” procedure. 


An optimization that is possible is to only add the condition to conds if a “wait” is 
actually performed. ‘That is, irsiead of locating the “add” operation at the beginning of the 
monitor procedure, instead it can be placed inside the then clause of the if statement 
immediately preceding the "wait". In addition, after the process finishes waiting on the 
condition, i.e. after being signalled, the condition created may no longer be needed. If no 
other processes are waiting on the condition, then it could be deleted from object conds. 


These optimizations would increase efficiency by keeping the size of conds as small as 


possible. However, they will not be performed in the examples here. 


Note that in certain situations, the range of possible values of the parameterizing 
variable t may be quite limited. If this is so, then it might be more efficient to add all 
possible values to the domain of conds initially, and eliminate the need for adding (and 
deleting) new conditions dynamically. This optimization, however, relies on extra 


information that is not contained in the specification but would have to be supplied in 
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addition by the specifier. In an actual system, this might be accomplished ‘by having the — 


system interact with the user to find out about the range of vatues of a given parameter. 


In order to signal the conditions contained ‘ an objet . type conditions{T3 the type 
must have an iterator "domain" for accessing one by one (in an wrinpecified order). all values 
of t for which conditions exist. By iterating through these values, all conditions on which ; 
processes may be waiting are tested. The sie for signalling that appears at the end of 
each monitor procedure is: | | | _ 


for t:T in conditions{T Hdomain(conds) do 
if condition $queue(conditions{T Weet(conds, t)). A om) 

then condition$signaKconditions{T Jeget(conds, t)), end; 
end; 


This serves to signal a process on any of the condition queues int Corids'whose predicates are 
true” “Where there are geveral different “Objects” of type’ ciniditionsIT1, due to different” 
combinations of gates with satisfiable qualifying predicates: then’this must’be generalized so 
that the conditions contained ih aff of them are tested lind’ signiéHed? (Notice that if the 
optimization mentioned: earlier ‘of ‘déleting ‘iinneeded tohditions were applied, then the 
implementation of the “domain” iterator would haVe to function correctly in a situation in 
which conditions could be deleted ‘while the iterator’ was “Suspendéd due to a “signal” 


operation.) 


‘For an example to illustrate the above discussion, sippose’ that “the ‘solution 
specification consists of the following euneies ‘entry condition: | 
For gate pe Hye l= tp: 
 coumttla(x) (x's tP™"y's ceuinitlghch 1" ype), 
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where variable.t is an integer. Then the parameterized quantities count({q(x) | (x = t)]*"*’) 


and count({q(x) | (x = t)I*"") would be implemented by objects of type countslinteger], as 
explained previously, named gentercounts and qexitcounts. They are created conceptually 
containing counts for all possible values of t, with all counts initialized to 0, and are 


updated by “incr” operations in procedures q_enter and q_exit, respectively. 


An object pentry of type condition siategei) cari be used to hold the conditions 
required. The predicate corresponding to the condition for any to is given by 
countslinteger]&get(qentercounts, to) = countslinteger}¥¢get(qexitcounts, to) 
_ Conditions are added to pentry by the statement 
conditionslinteger #add(pentry, y+l) 
appearing at the start of monitor procedure p_enter, which takes the same parameter y as 
operation p. The waiting in procedure p_enter then is accomplished by a wait on the 
appropriate condition, retrieved via a "get" operation: 
if countslinteger }¥get(qentercounts, y+l) # countslinteger]$get(qexitcounts, y+1) 
then condition$wait(conditionslinteger}$get(pentry, y+1), end; 
The signalling code at the end of each monitor procedure is: 


for t:integer in conditionslinteger #domain(pentry) do 
if condition$queue(conditionslinteger #get(pentry, t)) A 
countslinteger]éget(qentercounts, t) = countslinteger }$get(qexitcounts, " 
then condition¥signaKconditionslinteger ¥get(pentry, t)), end; 
end; 


The overall monitor for this example appears in Figure 5.4. 
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: Figure'5.4, Monitor for functional parameterized exampte 
patafun =-monttor; | 


qentercounts, qexiteounts: countslinteger] 
pentry: conditions[integer]; 


q_enter = procedure(x:integer), 
countslinté ger Winertgeritércounts, x}; 
for t:integer in conditionalinteper banaue) do 
if condition$queue(conditionslinteger #get(pentry, t)) A 
 ‘dountslintéger Byet(qehteroounts; tF = eéentsitute géyHget(qexitcounts, t) 
then condition$signaKconditionslinteger Wget(pentry, t)); end; 
end; sey ie ae Be .t ' Seriost Sy ey ee Neate : ar, 
end q_enter, 


q_exit = procedure(x:integer), 
countslinteger#incr(qexitcounts, x); 
for t:integer in conditions[integer #domain(pentry) do 
if condition$queuetcar ery; t)) nv 
countslinteger}€get(qentercounts, t) = counts[integer}get(qexitcounts, t) 
then conditiontsignaKeonditionstinteger Wpettpentry, t)), end; 


end, 
end q_exit; 


p_enter = procedure(y:integer), 
conditionslinteger}#add(pentry, y+l), 
if countslintegerWpetiqentercounts, y+l) * countslinteger#geuqexitcounts, y+1) 
then condition€wait(conditionslinteger]#get(pentry, y+l); end; 
for tinteger in conditionslintégerRdomaihipentiy) Woo 
if condition$queue(conditionslinteger Bget(pentry, t)) A 
countslinteger #eet(qentercounts; ty = courtsfinte ger¥eget(qexitcounts, t) 
then condition$signaKconditionslinteger Bget(pentry, t)), end; 
end, - : fof 7 Liha ae ! o ai 5 Ss < 
end p_enter; 


qentercounts := cauntskintegericreate(); 

gexitcounts := countslintegerMcreate(), . 

pentry := conditionslinregerIcreatel 
end parafun; 
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If the relation R(t, v) that qualifies an enter gate isnot functional, then the enter event 
must wait until.the entry condition represented by predicate Cot) is satisfied for all values 
of t such that R(t, v) is true. That.is, the entry condition. for an activation of p with 
argument vector v is given by the formula. 

Vt (Rit, ¥) 2. Cp(t). 
This is considerably more complex thar the entry condition Cp itlv)). for the case where the - 


relation between t and v was of the functional form t =. f{v), as discussed above. - 


As discussed above in connection with parameterized qualifying predicates that are 
functions, information about the range of possible values of the parameters could be used to 
optimize the implementation. Such information Soak make a much greater difference here 
where the predicate is a nonfunctional relation. In the absence of such information, which 
. would have to be supplied by the user in addition to the specification, the implementation 
to be presented here must. work under the assumption that, the.range of possible values of | 
each parameter is infinite. The ak is a severe penalty in both complexity and efficiency. 
It will be noted where user-supplied. range information could, be used to simplify and 


optimize the implementation. 


An assumption is made here that the predicate Cott) is initially oh for all values of t. 
That is, it is assumed to be something like 
count([q(x) | (x = OP") = count(lg(x) | (x -or", 
rather than ie apn? | 


count(lq(x) | (x = t)"*) > count({q(x) | (x = oF"). 


If this were not the case, and assuming there are.an infinite number of possible values of t 
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satisfying predicate R(t, v), then the entry condition | 
VRILy) 3 CA) 

could never be satisfied, since thete would always be some values of t (in fact, an infinite 
~ number) not satisfying the body of the quantified formata: ‘Here is ohe example of where 
information as to the range of possible values of t Would be helpful, since in fact t might 
assume only a small number of possible vahies. ‘Iti the absence of an explicit range, 
however, the range must be assumed to be ‘itifimtite. Atialysis to détermine what subset of 
the range could satisfy the relation R is clearly beyond the scope of this work. The 
assumption iad here appears to be satisfied for all cases of interest, such as the disk head 


Scheduler discussed in Chapter 6, and therefore not to be limiting. 


In implementing a solution specification in which an enter gate’ is qualified with a 
nonfunctional parameterized predicate, we again tise the type conditions{T]. The type T by 
which this type is parameterized, however, is fiat the type of the parameterizing variable t, 
but rather the type of the argument vector v, of more precisély of sore sub-vector of v. 
The specific sub-vector ctidseri ‘consists of exactly those componerits of V that are involved 
in relation R, which can be determined by syntactic inspection of R: The ‘type of this 


sub-vector will be denoted “vtype”. 


Because of the solution specification structure, thefé must be a separate condition 
variable for each subset of gates that could apply to a given activation. If processes making 
different activations pass through the same subset of gates, then they must do so in’ FIFO 
order. This is implentented by’ having ‘thie processes ‘wait ‘on the same condition, thus 


ensuring FIFO order. ‘fn'general, two activations p(v,) ahd p(v5) wait on the same subset of 
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gates when 

Ve(R(t, vj) # R(t, vo)). 
Ideally, this formula should determine whether two activations wait on the same condition 
variable. However, the logical pouek necessary to perform this analysis in general is beyond 


the scope of this thesis. Here again, information about the range of parameter values could 


overcome the problem. 


The implementation therefore makes a simplifying assumption, which is that two 
activations of an operation pass through the same set of gates only if the sub-vector of 
components involved in relation R are equal for the two activations. When the argument 
vectors to different activations share the sub-vector to which R refers, though possibly 
differing in other components, then they must pass through the exact same set of gates. 
This means that in the implementation they must wait on the same condition. For this 
reason, there is one condition for each value of the sub-vector of arguments involved in 
relation R. What is assumed here is that two activations with different sub-vectors always 
pass through different, through possibly overlapping, subsets of gates, so that in the 
implementation they can wait on different conditions. This assumption is true for the disk 
head scheduler of Chapter 6, for instance, and where the relation R is something like 

t<x, 
where x is one of the arguments in v. This is because if two values of x are unequal, then 
there exists some value of t that is less than one but not the other. An example of where 
the assumption breaks down is if R is of the form 


t = absolute_value(x), 


146 -— 
since x and (-x) satisfy this relation for the exact same set of values of t. 


The object conds of type cnditionsivypel is diferent from the caresponding object 
af Eype comeitonel) im the «ase OF a: funcnomn)Fetating. As belore. sine objec ie created. 
initially empty, and conditions are added to dynamicalty in the monitor “enter” procedure 
prior to the code for waiting. Howeve: since the Sere sascciated with each condition” 
in conds is of the form as 

VE(Rt,¥) > Coty, 

it is necessary also to miaintain a ‘tecord of théte valués-of the pdrameterizing variable t that 
have occurred, sifice these are the values for which’ T (0, whith ‘by ‘assumption is initially” 
true, may have become false. Tis ‘is dccoinplished by saving (he’set of all relevant values 

of t in an object “tset™ of type setiT) (whete T is‘again the type oft). ‘The object tset is” 
initially created ‘as the empty Set. Elements are added to the set by the “insert” operation. 
An “insert” operation must be performed in ‘act’ moftitot protedute in Which quantities 
involved in the predicate Cty are updated. “There is also’ ain ‘iterator “elements” ‘for 


accessing the elements of:the set. 7 es 
As was the case mentioned earlier for type conditions[T 1 information from the user as 
to the range of possible values of t would permit an optimization to be performed with 


respect to the object tset. If the range is relatively small, then all relevant values can be 


inserted into the set beforehand. This would eliminate the need to dynamically insert 


ao Meee RP be 


values. Note that another optimization mentioned in connection with conditions[T], that of — 
deleting elements when no longer needed, cannot ‘be applied to tset, since any value of t that 


has occurred may be relevant and must therefore be saved. 
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The code in procedure p_enter(v) for testing and waiting on the condition in object 
conds is given by: 


for t:T in set[T]telements(tset) do 
if R(t, v) A (7 Cott) then 
condition$wait(conditions[vtype}¥get(conds, v)); end; 
end; 


This code implements waiting on the entry condition 
vt (R(t,v) > Celt). 
The required condition is added to conds by the statement 
conditions[vtype}tadd(pentry, v), 


at the start of the monitor procedure. 


Notice that the “elements” iterator may be suspended in the middle of execution due to 
the execution of a "wait". While it is suspended, new values of t may be added to tset by 
other monitor procedures. The iterator must be implemented so as to function correctly in 


such a situation. 


Signalling at the end of each monitor procedure is complicated. The signalling code 
must iterate through all values of z (a sub-vector of v) in conds, for each one testing 
‘ whether its predicate is true by iterating through all values of t in tset. This code involves 
an iterative loop within an iterative loop, with a “signal” operation performed at the 
completion of the inner loop if all gales of t for which R(t, z) are true satisfy the predicate 
C p(t). (We take the liberty of saying "R(t, z)" rather than "R(t, v)", since z contains all the 


components of v that are involved in R.) The code is of the form: 
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for zNtype in conditions[vtypel¥domain(conds) do . 
. if condition¢queue(conditions{vtype}éget(conds, z)) then 
ok:boolean := true; re ee 
for tT in set{TWelements(tset) do 
os BREDA DINE cs ce 
ok := false; end; 
if ok then condition$signaKconditionslvtypel¥get(conds, z)), end; 
end; oR UN SP 
end; ae ee AE een Oe a ae ca 4 
The boolean variable ok keeps track of whether the Predicate Cp(t) is true for all values of 
t for which R(t, z) is satisfied. If ok is still true after the end of the inner loop, then 
Vet(R(t,z) > CA(0), 
is true for the given value of 2, and therefore the conidition should Be signalled. Notice that 
if there is a process waiting on the condition queue'fot z, there must’bé at least one value of 
t for which R(t,’ 2) is trué; becatise otherwise there would have been no reason for the 
process to have performed a “wait”. As before, in a situation in which there is more than 
one object of type conditions[T], the conditions in each such object must be tested and 


signalled by code of the above form. 
As an example, consider a solution specification consisting of the condition: 
For gate Tp(y) Hy eur | — 
counttiq(x) [ (x = t)]"**) = couat(tglx) 1x = OI) 


Hofeh WAT ia? 


where variable t is an integer. Then as in the previous example, count({q(x) I(x = rte) 
and count([q(x) | (x = t)}**") are implemented by objects of type countslinteger], named 


qentercounts and qexitcounts, respectively. An object pentry of type conditionslinteger] is 
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involved in relation R. ‘An object’ bet gcegs aaeacicel cells the. values of t, to which 
values are added by the statement . 2 = 

setlinteger Binsertipentry, x 
in monitor procedures q_enter and q exit: The‘osde for oe in provedurs p_enter is 
given by 


for tinteger in setlinteger telements(tset) ee 
if y<t a countslintegerlbget(qentercounts, t) a * 
countslinteger ¥get(qexitcounts, t) 
then 7 sete BS ae Steet eee 
condition$wait(conditionslintegeriget(pentry, v)); end; 
As before, the required condition is added to pentry at the start of the p_enter procedure by 
the operation — | 
conditioner alpen, rm 


The signalling code at the end of each monitor x procedure is: 


- 150 - 


for zinteger in conditionstintegevedomatii(pentr yy #6” 
if condition Squevielcondisionstintegeritgetipentey, 2)) then 
ok:boolean := true; 
for t:integer in setintgerHelementstst) do - 
if z<t a ” countsiniegeritg ‘ex(qetitércounts, t) = 
~onuntslintegentig digexisenunts,t). 


then ok := false; end, 


end; 


if ok then condition$signaXconditionstf taper agerlp try, 2), end; 


end; 


Sq08 


end; 


ae — 


The monitor for this Seam cia in ees 55. 


th 


A hamper of ae of the crarraion rou discussed here aber in Chapter 


re He Sue ee eiae; fe gfe he 


: 6. "These scarnpies gcuiaily illustrate the entire synthesis process, "starting with problem . 


pretation: of the type Creed in Parties aa 2 peniee to the construction of 
conte 
equivalent solution specifications + via the method 1 presented in esc 4, and finally — 


peneane these solution specifications into ‘monitors. as | discussed. in ‘this ‘chapter. In 
particular, the last example of Chapter 6, the “disk head scheduler”, illustrates the 


implementation of qualified gates involving parameterized predicates. 
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Figure 5.5. Monitor for nonfunctional parameterized example 


paranon = monitor; 


gentercounts, gexitcounts: countslinteger), 
pentry: conditionslinteger]; 
tset := setlinteger], 


q_enter = procedure(x:integer), 
countslinteger$incr(qentercounts, x); 
setlinteger]#insert(tset, x); 
for z:integer in conditionslinteger#domain(pentry) do 
if condition$queue(conditions[integer}$get(pentry, z)) then 
ok:boolean := true; 
for t:integer in setlinteger}¥elements(tset) do 
if 2<t A countslinteger¥get(qentercounts, t) * 
countslinteger$get(qexitcounts, t) 
then ok := false; end; 
end; 
if ok then condition$signaKconditionslinteger #get(pentry, z)); end; 
end; 
end; 
end q_enter; 


q_exit = procedure(x:integer), 
countslinteger #incr(qexitcounts, x), 
setlinteger}finsert(tset, x); 
for z:integer in conditionslintegerRdomain(pentry) do 
if condition$queue(conditionslinteger Rg et(pentry, z)) then 
ok:boolean := true; 
for t:integer in setlintegerfelements(tset) do 
if z<t A countslintegerget(qentercounts, t) # 


countslinteger]$get(qexitcounts, t) 
then ok := false; end; 
end; , 
if ok then condition$signaKconditionslinteger#get(pentry, z)); end; 
end; 
end; 
end q_exit, 


p_enter = procedure(y:integer), 
conditions[integer fadd(pentry, y); 
for t:integer in setlinteger#elements(tset) do 
if y <t A countslinteger}tget(qentercounts, t) # 
countslinteger }¢get(qexitcounts, t) 
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then condition$wait(conditionslinteger}¥get(pentry, v)); end; 
end; : 
for z:integer in conditions[integer #domain(pentry) do 
if conditionSqueue(conditionslateger ge peeyCy,, 2 a then 
ok:boolean := true; are 
for t:integer in setlintegerbelements(tset) do recs 
if 2<t A countslinteger}¥get(gentercounts, t) vy 
sa ih i 0 
then ok := false; end, 


end; 


f ok then + ondndgandoningo ae 2 end; 
end; . K 


end; 
end p_enter; 


gentercounts := countslinteger3#createl) 
gexitcounts := countslinteger}écreate(); 
pentry := seas pha 
tset := setlintegerIecegate(), 

end paranon; 
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Chapter 6 


Complete Examples of Synthesis 


6.1 Introduction 


This chapter presents a sériei of examples of the complete synthiesiz method. Each 
example starts with a problem specification, and derives an equivalent solution specification 
via the method presented in Chapter 4. This solution specification is then translated into a 
monitor implementation in the manner outlined in Chapter 5. The examples chosen for 
this chapter are problems that commonly are addressed in technical literature on 


synchronization. These are the bounded buffer, two different versions of the readers-writers 


problem, with writers’ priority and alternating priority, and the disk head scheduler. 
6.2 Bounded buffer 


The first example in this chapter is the specification of example 9 from Section 2.7, the 
“bounded buffer". The problem specification given in Chapter 2 is repeated here, to be 
denoted bb: 

(dep*** = rem") A (rem,o"* = dep,.no™™) A 

(dep°"* = dep, ,°"") A (rem,°** => rem, ;°"**"). | 
The specification bb consists of four conjuncts, and the solution specification is constructed 
by analyzing each conjunet separately. Since each individual conjunct is quite simple, the 
. analysis is straightforward. For purposes of reference, the four conjuncts are denoted bb), 


bbo, bbs, and bb,. 
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The first conjunct to be analyzed is bb,;~ | 
(dep,°"4 => nem). Pe eee 
This conjunct specifies that the i-th “deposit” activation must finish before the i-th “remove” 
activation can start. This constraint ensures that no attempt is ever nade to centove - 
message from the buffer before it has been deposited in, Since there are no argument 
constraints in the conjunct, the first step. in the analysis is the identification of which event 
expressions are mentioned. The set of event expressions. in the conjunct is. given by 


2 Evexp(bb)) = (dep, rem"), 


_ The inext step is to construct the possible orderings among the events represented in 
the set Evexp(bb,). With just two such events, only two orderings are possible: | 
ay ieee Nata 18 SOE = 
(2) (rem;*"" => dep,*"") 
In evaluating whether each is valid or invalid, it is obvious that the first is valid, while the 
second is not. Equally ‘obvious is the fact the the offending ‘event in ordering (2) must be 
the first event, namely rem,*"*. This mearis that a sohition specification condition must be 


derived for the rem*"*’ gate. 


Characterizing the state at each event in the rem°™. eyent class,. one obtains 
characterizations ¢ and Co for event rem,*"*" in orderings (1) and (2), respectively: 
cy Ai (countidep™) 2 i 4 count(rem™*) < i) 
Cg: Ji (count(dep™") <i A count(rem?™*) < i) 
; } 
With only one valid ordering, the disjunction of valid ordering characterizations D, is 


Simply c,. Similarly, the disjunction of invalid ordering characterizations Dj is Co. The 
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preliminary condition, given by (Dy 4 (~ Dj), then becomes 
Ji (count(dep*™**) 2i A count(rem*™*) <i) A 
V i (count(dep™") > i v_ count(rem*"*’) > i), 
which reduces to 
Ji (count(dep*") 2 i > count(rem*™*")). 
The quantified variable i can be eliminated, resulting in the simplified formula 
count(dep*™") > count(rem*"*’). 
_ When tested, this condition is found to satisfy the single valid ordering, ordering (I), 


showing it to be the correct condition obtainable from conjunct bb. 


Each of the other three conjuncts can also be analyzed quite easily. The second 
conjunct is bbo, 
(rem,°** = dep, .n*"*), 
This prohibits more than N consecutive “deposit” operations without at least one “remove” 
operation, preventing overflow of the buffer. The set of event expressions for this conjunct 
is 
Evexp(bbo) = {rem,°", dep, wee} 

The two possible orderings are: 

(1) (rem,*** = dep;,.n°"*") 

(2) (dep; nr" => rem;**") 
Of these, the first is valid, while the second is invalid, with the offending event in (2) being 


enter inter 


dep,.n A condition must be derived for gate dep® 
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The state characterizations fot event dep." in otderings 41) and (2), respectively, 

are given by c and co: me 3k ee . 

cy Ji (counttrem*™*)> i A counttdep™ « isN). 

Co: Ji (count(rem*"*) <i A count(dep*™*") < i¢N). 
The preliminary condition, (D, “ (~ D,)). is equal to (c, rat (to): 

‘Fi (cownt(rem*™) 2 i A” coninttaeph™) <'tsN) on 

V i (count(rem®*)'2'f V counttdep™*) > i+N), 
which simplifies to i 
_ count(fem™*) > 'count(gep™*) = N. 

This is the correct solution specification condition for conjunct bbo. | Notice that variable N 
in the above eeeinilan is treated asa ‘aiati since it is the saaiabed to the abstract data 


type itself. Far this reason, it is not quantified and. cannot be eliminated as variable i is. 


applies ‘to operation’ “dep” and 
‘bby to operation “rem*. ‘ Therefore, whatever ‘condition is vbtiltied fron ‘bb; for gate 


enter 


dep applies in corresponding form for rem*™* due to bby. The constraint specified by 

each is that activations of the given: Operation must be ritituatly exclusive and must proceed 

in first-come-first-served order. This prevents interference by ‘cosicurtent activations of the 

same operation manipulating the same “focal data, and guarantees that messages are 

_ deposited and removed in the proper order. For eohijunct bbs, 
Evexptbbs) = {depi™, dep jy 

The two possible orderings are: | pe Diep aa Ee 


(i) dep" => dep," 
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(2) (dep, ,.°"" => dep,***) 
Ordering (I) is valid, but 42) és not. The offending. exent:in (2) ts. dep,, a. so a condition 


is required for gate dep*"*" 


The state chavacterizations for. event dep," in, orderings (1) and (2), respectively, 
are given by q and CO, le by i a ae, Ss A RS Bere Te oh go 
kp Bi (count(dep"™) 2a, n. anuntidep’?*") s-i*h) 
cae. Jifcountidep"™).<.4 .ceunsidept) <i 
| The preliminary condition, (D, A (- Dj))..is given by {cA eh) 


3 i (count(dep™) 2 i A..6 


This reduces to simply _ . 


© ount(dep ea! one aoe le 


which is the correct solution specification. .gonditios 


correct condition for bb, is 
count(rem™™”) = count(rem™™*) 


for gate rem*™™, 


wh ait 1 segGaioh a2) Roasid ME Oo. a 
each gate the conditions ‘obtained aacpabe — the individual Laapeah This obtains 


the following overail conditions: 
For. gate dep". -_ 
. coumtren™) > even N nA p countiep - counaep™) 


B ffP sige: ud} 
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For gate rem*"*’: 


count(dep*™*) > count(rem®™") A count(rem**) = count(rem*™*) 


The monitor to implement this solution specification must have four integer variables, 


exit) 


depn, depx, remn, and -reinx, to’ represent. the quahtities codnt{dep*™"), count(dep 


count(rem*"*’), and count(rem®*). There also must be two condition vabiabies depentry 
and rementry, corresponding to the’ entry ‘conditions’ for ‘gates dep’ and rem®"*’, 
respectively. The boolean predicates associated with these conditions are 

depentry: remx > depn.- N' a: depn‘s depx — 

rementry: depx > rem A ‘femini #‘remx | 
Since the request events for the two operations are not used iri‘ the specification, there is no 
need for procedures to implement the corresponding gates. The monitor for the bounded 
buffer is presented in Figure 61. Since the intention: is for'the monitor to be contained 
within the type-module for the abstract type buffer(N), the Vutidbte ‘N inside the monitor is 


bound to the parameter of the type. 
6.3 Writers’ priority database 


The second example in this chapter is a problem that was introduced in [Cou7i).. The 
data abstraction in question is a sistas 4 which two operations are defined: “read” 
accesses the database sithiout cnavaing it ‘ all, sd “write” igiaies the database | In order 
to ensure consistent accessing and updating, these two operations must obey the 
"readers-writers” property embodied in example 3 of Section 2.7. In addition, the scheduling 


' policy desired is for activations of operation “write” to have absolute priority over those of 
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Figure 6.1. Monitor for bounded buffer 


bb = monitor; 
‘depn, depx, remn, remx: integer; 
depentry, rementry: condition; 


dep_enter = procedure; 
if (remx < depn-N v depn * depx) then condition$wait(depentry), end; 
depn := depn +¢ 1; 
choose 
condition$queue(depentry) A remx > depn-N A depn = depx: 
condition¢signaKdepentry), 
“condition$queue(rementry) A depx > remn A remn = remx: 
condition$signaKrementry), 
end; 
end dep_enter; 


dep_exit = procedure; 
depx := depx ¢ I; 
choose 
condition¢queue(depentry) A remx >depn-N A depn = depx: 
condition#signaKdepentry), 
condition$queue{rementry) A depx > remn A remn = remx: 
condition$signaKrementry), 
end; 
end dep_exit; 


rem_enter = procedure, 
if (depx < remn Vv remn # rani) then condition$wait(rementry), end; 
remn := remn + 1; 
choose 
condition$queue(depentry) A remx >depn-N A depn = depx: 
condition¢signaKdepentry), 
condition$queue(rementry) A depx > remn A remn = remx: 
condition$signaKrementry), 
end, 
end rem_enter; 


rem_exit = procedure, 
remx := remx + 1; 
choose 
condition$queue(depentry) A remx > depn-N A depn = depx: 
condition$signaKdepentry), 
condition$queue(rementry) A depx > remn A remn = remx: 
condition$signaKrementry), 
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end; 
end rem_exit; 


depn, depx, remn, remx := 0, 0, 0, 0; 
end bb; 
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operation "read", in order to ensure that each “read” operation accesses the most current 
version of the database. Therefore, to the “readers-writers” specification of example 3 must 
be added an instantiation of the priority specification embodied in example 4 of Section 2.7. 
The overall specification is the following, to be denoted wpdb: 

((write°"'*" => write") =) (write,*** = write;*™*")) A 

((write;**" => read, °"'*") Vv (read, **™* => write,°"'*")) A 


(write,"***! => read") > (write => read *"'*")). 


The specification contains three conjuncts to be analyzed. Of these, the third conjunct 
has already been treated in detail in Section 4.2, with the names “p" and "q" used for the 
operations instead of “write” and “read”. By the analysis in that section, this conjunct 
contributes the condition 

count(write’™**!) = count(write*™*’) 


to the gate read®™"", 


The other two conjuncts of the specification remain to be analyzed. They will be 
referred to as wpdb, and wpdbo, respectively. The first conjunct wpdb, is 
(write 2"'" => write") > (write,*"" => write"). 
As with the bounded buffer example, there are no argument constraints in this or any other 
conjunct. The set of event expressions contained in the conjunct is 
_ Evexp(wpdb)) = {write*"™, write*"*, writeo™*"}. 
There are three possible orderings among these three events: 
(1) (write*"'" => write*™" => writeo""") 
(2) (writer => write?" => write") 
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(3) (write enter =, writes => write, ret) 


When ordering ay is substituted into the conjunct wpa, the rest is the formula (TRUE: > 


TRUE), or + simply TRUE, : so that ordering W). is s valid. “Ordering Qi is fake valid, since it 


- evaluates wpdb, to the feist (FALSE > FALSE), which similarly reduces to 5 TRUE. 


Ordering (3) substituted into wed evaluates to 0 (TRUE, > FALSE), or "FALSE, so that 


ordering (3) is invalid. 


Comparing invalid ioeerinE: (3) with the valid meee (i) and (2), the longest 


matching prefix is the one-element "sequence “fwrite™, matching ordering (). The 


oretng event in (3) is therefore the event nt following ‘this prefix, which is write | This 


means that a condition must be derived for the “writes gate. 


The state must be characterized. at the point-ef each event in the write*™'*’ class that 


either occurs within a valid ordering or is the offending event in an-énvalid ordering. : 


There are five such events, writee"" and ge in each of the two valid orderings (1) 
and (2), and writes" i in invalid ordering Q), where it is $ the © offending e event. Denoting the 
characterization at event write; otis in ordering (a as yp ete: etc bes = | 

qj: 3 (i, j) (count(write® nter) <i A count(write™™¥*r) < <j A - count(write™) < i) 

Ty 3 (i, 1) (count(write*™*) iA count(write™™") < 3) A count(write™*) > i) : 

Cog Ali, j) (count(write* ap <i A count(write™*7) < jan \ count(write™**) < i) 


Co; 3 (i, j) (count(write™*") < <i A count(write*™*7y > i A ‘count(write™) < i) 


cay 3 (i, j) feouotiurig =) Di A _countwriten < i n \ count(write ory i) 


- 163 - 


The four characterizations. from the valid orderings are disjoined to form Dy: 

3 (i, j)((count(write™™*’) <i” count(write™*) <i) v count(write*™*’) < j) 
Since there is only one invalid ordering, the disjunction of the invalid ordering 
characterizations Dj is simply c3;. The preliminary condition is given by (Dy A > (D,)): 

3 (i, j) (count(write®™*’) < i A count(write®™) <i) v count(write®"*) <j) A 

V (i, j) (count(write*™*’) <i v_ count(write*™*’) > jv count(write®™") > i). 

This reduces to 
V i (count(write™*") <i v  count(write®*) > i), 

which in turn simplifies to © - 
count(write™") = count(write™™). 
When this condition is tested for both write*™*" events in each of the two valid orderings, it 


is found to be satisfied in all cases, showing that it is the correct condition. 


The other con junct in the specification is wpdbo: 
(write;*** => read,*™*") v (read, °** => write,*""*")). 
The set of event expressions contained within wpdbo is given by 
Evexp(wpdbpo) = {write,"", write", read, *"'*", read, °""}. 
There are six possible orderings of these four events: 
(i) write;*"'*r = write," => read, °""" = read, °"* 
(2) read, *ter => read, ™** = write,*"e" => write" 
(3) write°"'r => read, °"*" => write" => read, °**" 
(4) write," => read, °"*" => read, ** => write," 


(5) read, *ler => write*"" => read, *™" => write," 
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(6) ready ome => write; orter a5 write" => 'tead, 


a, "4. Ng Se SSE se te 


When tele, is evaluated for €ach of i 2 orderings, the fesuks, for orderings (td and 
@) are RUE v FALSE) and APALSE \ v / TRUE), respectively, each of which equals 
TRUE. This means ie _ orocsings (1) ) ana (2) are valid, For each of. iad other four 
shall ‘the resuking fornia is (FALSE v FALSE), which, gyal, FALSE, showing each’ 


Thar E95 £2 £3 


of these crderiips to be invalid. 


The next step isto identify’ the ‘offending’ event in tach’ of the four invalid orderings. 
Both orderings (3) and (4) match valid ordering (1) as far as the Yirdt ‘event, write: ‘The 
- Offending event in each is the second’ évent, ‘whic ity OER’ cases is read, °"*", Similarly, 
-orderirigs (S}arid (6) beth inate orderifig (2) sinialuaua Bvthi: ad", 5 that the 
offending event #f-each® case ‘Is: wie; He heidi Went “int' thd “Sidering. Solution 


specification conditions must be derived for two gates, read" and write™™*". 


In order to derive tte’ condition for gate reads, iit is necBisar} to characterize the 
state at certain events in the read™* class The events itt ithe “thas ockurring’ in valid 
orderings are the read," events in ordetings (1) ind QS PHS Stfending events in the 
stig ‘Band Denoting these 


class are the occurrences of read, ini br 


characterization as ¢,.i¢y'ett,, they wre: ~ 
Cig: 24 K) (countlwrite™) 2 iin cotint(write™) 2 i A 
* eousit(read™) <'k A‘ comntiréad™*#) by! 
, cor pen eens ee ‘Sacre 
© examtrendtiny 0 ah ay 


- 165 - 


c4-: 3 (i, k) (count(write™™*") > i A count(write™) <i A 
count(read®"'*") <k A count(read®*") < k) 
C4y: 3 (i, k) (count(write"™*) 2 i A count(write™) <i A 
count(read®*"") <k A count(read**) < k) 
The two disjunctions are given by Dy = (cj, V Co,), and ; = (ca, V C4y): 
Dy: 3 (i, k) ((count(write*™*") >i A count(write™™*) > i) v 
(count(write™™*’) <i A count(write®™*) < i)) a 
count(read®"'*) <k A count(read®") < k) 
D;: 4 (i, k) (count(write*™*") > i A count(write™*) <i A 


count(read®*") < k A count(read®*) < k) 


The preliminary condition is formed by the expression (D, A (~ D,)), 
3 (i, k) ((count(write*™*") > i A count(write***) > i) v 
(count(write™'*) <i a count(write™") < i)) a 
count(read®**) <k A count(read®*) <k) A 
V (i, k) (count(write*™) <i v count(write™*) >i v 
count(read*™*") >k Vv count(read®"*) > k). 
This can be simplified to 
v i (count(write*™™) <i v count(write®™*) > i), 
which in turn is equivalent to 
count(write®*"*" = count(write®™*). 


. This condition satisfies both valid orderings (1) and (2), and so is correct. 


Fe Fes 
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Because of the symmetry of the specification wpdbo,: and: therefore of the orderings, 
the derivation of the condition for gate write" is completely isomorphic to the above 
derivation. Rather than repeat essentially the same derivation, I will simply state the result, 
that the condition for gate write™™*’ as a result of this conjunct is 


count(read*™*’) : count(read®**), 


The overall solution specification for specirication wpdb is constructed by conjoining 
the conditions from the individual conjuncts. The Sainte conditions are: 
For gate read®™*: | _—~ 
count(write"®™=*") = count(write®™’) A count(write*™*") = count(write®**) 


wee 


For gate write®"'*", 


_count(write®"*’) » count(write”™") A countiread*™*") ~.count(read®*") 


In the monitor into which this solution apisificatica translated, there must be integer 
variables wr, wn, wx, rn, ine rx, representing count(write'*™*), count(write*™*’), 
count(write®*"), count(read®™"), and count(read®**), ‘feapoetivedy. “There must also be 
condition variables writeentry and Vendeitry coreponding the conditions in the solution 
| Specification. Their associated boolean predicates are — 

readentry: wr=wn A wn = wx 
writeentry: wn = WX A I= rx 
Notice that count(read’*™*') does not appear in the solution specification, so that no 


variable is needed for it, and thus a procedure read_request is not required. The resulting 


monitor appears in Figure 6.2. 


Cie ii carne 2 OREN 


wea 
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Figure 6.2. Monitor for writers’ priority database 


wpdb = monitor; 


eR RN a ot ag RR BIE 


wr, wn, wx, rn, rx: integer; 
readentry, writeentry: condition; 


write_request = procedure, 
wr := wr +]; 
choose : 
condttion$queuefreadantey): A. WER. wn; A wne WK: 
condition$signaKreadentry); 
condition$queue(writeentry) A wn = wx A rm = rx: 
condition$signaKwriteentry), 
end; pote fea 
end write_request; 


write_enter = procedure, 
if wn * wx Vv ie 5G thie oadesslpesalatiasbiyi one 
wn := wn +1; 
choose 
Sa Re at ee A wrewn A wn = wx: 
condition$signaKreadentry), 
condition$queue(writeentry) A wn = Wx A 1m = rx: 
condition$signaKwriteentry), 
end; 
end write_enter; 


write_exit = procedure, 
WX := wx «|; 
choose 
condition$queue(readentry) A wr=wn A wn = wx: 
a . 
' condition$queue(writeentry) A wn = wx A rm = rx: 
condition$signaKwriteentry), 
end; 
end write_exit; 


read_enter = procedure, 
if wr # wn V wn = wx then condition$wait(readentry), end; 
m:sim+ti; 
choose ; , 
condition$queue(readentry) A wr= wn A wn = wx: 
condition§$signaKreadentry), 
condition$queue(writeentry) A wn = wx A rn = rx: 
condition$signaKwriteentry), 
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end; 
end read_enter; 


read_exit = procedure; 
rx = rx +4; 
choose : 
conditionfqueue(readentry) A wr = wn A wn = wx: 
condition$signal(readentry); 
condition$queue(writeentry) A wn = wx A rn =rx: 
conditiontsignal(writeentry); 
end; 
end read_exit; 


wr, wn, wx, rn, rx := 0, 0, 0, 0, 0; 
end wpdb; , 
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6.4 Alternating priority database 


The next example is a variation of the previous one. Again the data abstraction is a 
database, with operations “read” and “write” obeying the "readers-writers” property. In this 
case, though, the relative priority of the two operations is to alternate, so that in a situation 


in which activations of both operations are being continually requested, the result is that 


- first a single “write” activation executes, then all waiting “read” activations, then the next 


“write”, etc. This scheduling policy is the one followed by the readers-writers example in 


(Hoa74], and is referred to as the “fair database” in [Gre75). 


The specification for the “alternating priority" database is given by: 
(write°"'" => write") > (write°™" = write") A 
(write*"" => read,*"r) v (read, °™* => write;*"'*")) A 
(writen => read‘! => write") > (read => write, i") A 
(writers! => read rere! = write,*""*") > 
Im (read jr" = write," => read "'*")) 

The first two conjuncts express the “readers-writers” property and are the same as for the 
previous example wpdb. The analysis of the previous section need not be repeated here. 
The last two conjuncts state the “alternating priority” property. The third conjunct apdb3 
requires a “write” activation to wait to enter until all “read” activations that were requested 
during the execution of the perevicas “write” have done so first. The fourth conjunct apdb, 
prevents an activation of “read” from entering until an activation of “write” has exited, 


assuming that there is at least one “write” that is waiting at the point at which the “read” is 


requested. This prevents new “read" activations from continually entering. Solution 
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specification conditions must be derived for these two con juncts. 


The first conjunct to be analyzed is apdb,: 
(write, ne” => read wane! => write") > (reads => write, °°") 
The set of event expressions in the conjunc ‘is’ 
| Evexp(apdb) = {write*"™", write", write; °°, read vores read Fane 
With these five events to be ordered, there are eightéén possible orderings. They appear in 


Figure 63. 


When each of these orderings is used to evaluate the specification apdb3, odes (1) 
through (15) are found to be vatid, while orderings (16) through’ (18) are invalid. Since 
ordering (16) matches ordering (1) through the first three events in each, the offending event 
in (16) is the fourth event write, ,,°"". Each of the other two invalid orderings (17) and (18) 
matches orderings (1) through (3) as far as the first two events, 30 the offending event in 


each is the third event, also write. ie This ‘means that a condition must be found for 


1+ 


"gate write’™*’, 


enter 


The characterization of the state at the point of the offending, event write; a (in 
ordering (16) is given oy | . | 
3 (i, j) (count(write*™*) > i A count(write*™*’) < (i +1) A count(write*™") zi A 
count(read’*™"*") > ' A count(read*™) < j). 
The seater for orderings (17) and (18) are identical, namely 
3 (i, j) (count(write®™*) 2i A count(write?™*") <(@i+lD an count(write™*) < i A 


count(read'*™"*") 2 j A count(read*™'™) < j). 
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Figure 6.3. Possible orderings for apdbs | 


(Ll) writes" => read ores! = write" => aa Ps write," 


(2) write," => read ‘ows! => read °" => write" => write; ,; 


(3) write*™" => read "ene mp ead wees er mh write | 


(4). write?" => write," = rend Pret =p read HY => write," 


(5) write" : mad write," = read sewn =e werite; 4" > read; 

en ont , exit = enter ent 
(6) write" => write,™" => write, gr. =. rend [ew => read mntor 
(7) read"! => read oe" =9 write er => write," => write, o"" 


(8) read, ie => read" => write" => write; J" => write,*™* 


(9) read, esas => write," => 2 me => ren => write, oo 


(10) read Vue => > writer = read = => write, °°" A a -> write ** 
(il) read ee" = > write, = aa =} rend => write; exit 


enter exit” 
(12) read “weet => write" => si " xh _— = =i 


(14) read /nwest = write"r iia 8 aig aie read rr : 


(15) write,°"'" => write, .°"" =>. write, reagroe an reader 
(16) write" => read "ee! =», aie => write jo" =? vead;" ot 
(17) write," => read)" = => write, go cad > write on" = read 


(18) write," => read = => write," => reg => write 
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The disjunction of these two characterizations is equal to Dj: 


Dj: 3 (inj) (count(write™™*) « i A edunt(read"™™*4)> jn cowit(read™™*) < j). 


The state also. must be characterized. for avents-write2"" and: write; ,.°"""" in each of 
the 15 vatid orderings. This means that: 20-separate characrertzatjons mus be formed. 
However, tiany of the characterizations for different eee are identical: In fact there 
are only nine distinct characterizations, which are listed here: . 

(a) 3(i, ji (count(write"™) 3 i A countiwrite) < ( +1) a ‘count write) >i A 
| “cotnifread™e 2 > i A comnttenatn 2 2 D 
(b) 3 (i, D (count(wrte™) 21 A counitwrie™) « . D A count nt >in 
| count(read™ > > ja ‘countireaa™™) < ne 
(c) 3 (i, j (count(write™™") > zi A. count(write™) <(isD a eount(write"™") 2 2in 
count(read’""™™) < ja coumt(read’*" ep 
(d) 34, 1) (ooumtiwrte A comntiwrite’™) «(i+ 1) A céunt(write™) <i A 
‘Gountiread’**) =} «A count(rend™™"7< j) 2" 
(e) 3 i, ee aad nN comtit(wr ite . <@s 1) A cout(write writ) cin 
couiitjeda™™ty > j ja “ count(réad™") < > | 
() 3G, p countiwritet*¥) cin counetwritet™) <i s A count(write™™) <i A 
count(read"****") > j a count(read*™**) 2 j) | 
(g) 3 (i, j) (count(write*™*’) > i A count(write*™) < (i +1) A count(write™*) <i A 
count(read"™*#) 2 j A count(read*™*) 2 j) 
(h) 3 (i, j) (count(write rier) 2 i A count(write™™) < (i +1) A count(write™) <i A 


count(read’*0**!) > j ~ count(read*"*’) < j) 
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(i) 3 (i, j) (count(write®™*") > in count(writet"') <(isl) A count(write™) <i A 
| count(read"****!) <j A count(read*™*’) < j) 
The disjunction of these nine chardcterizations is D,, which reduces to: 
Dy: 3 (i, j) ((count(write*™*’) = i v_ count(write*™") <i) a 


(count(read'*’**") > jv count(read*™*") < jp). 


The preliminary condition is (D, A (= D)). 
| 3 (i, j) ((count(write™*’) 2i Vv count(write®**) <i) A 
(count(read"***') > j v count(read®*™*’) < j)) A 
V (i, j) (count(write*™*") « i v count(read’*™**') <j v count(read*™*’) > j), 
which when simplified reduces to: 


count(read"®?"*"") = count(read*™**. 


This condition must be tested for both writer events in each of the fifteen valid 
orderings. In doing so, it is discovered that the condition is not satisfied for the following 
events: 
enter 


write; in orderings 13 and 14 


write; .°"'*' in orderings 5, li, 12 and 13 


An event must be found that precedes each of these events, as well as the offending 


event in each of the invalid orderings. The only such event is read (ww"l. The state is 


therefore characterized at this event in each of the orderings in question. In ordering (5), 


the characterization at event read (ern! is: 
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3 (i, j) (Coount(write™*) @ read'*™"*] 2 in 
[count(write™™*) @ read") < (i +1) A 
[count(write™™) e reader} > in 
[count(read"®**) @ reader") <j An 
[count(read®™*") @ read"errrt} « 4). 
In each of the other valid orderings in question, it iss 
3 (i, j) (count(write®™*’) e reads] <i , 
[count(writet™") e read"™at <( +1) A 
Teount(writet™) © readies) < _ oo | 
[count(read"*™**") e read >t] <j a 
[count(read*""*’) e read’*avel] < jp. 
This'means that the formula D,’ is given by ‘ee janes of these two, or: 
| Dy’ 3 (i, j) (leountéwrite™”) @ read’**"*] 2 in. 
[counttwrite™") @ read’) 21) v 
([count(write™*") e read") < i A 
[count(write™") @ read’*"*'} <i) A. 
[count(write*™*") @ read""*5 < (i+ 1) A 
[count(read"****") @ read] < j a 
7 [count(read***") e read’! < j). 


. The characterization at read ‘eat! in each of the three invalid orderings is the same, 
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AG, j) Goountiwrite™) 9 pend") Zin 
- feount(write?™).@ read") <.i):A 


This formula is therefore.D;.. The weakening term ts fermed by D,’ a (- Dy’): 
3 (i, j) (Coount(write™™™) e cepts 2ia 
fcountwrie™) @ read 2 > ) ie 
 (count(write’™") @ read™™*) < 
| cee adi pith _ 
" Teounterintr rend +1) » a a 
[count(read’™™) @ read <j A 
[count(read*™”) e-rend*"""'] <j) Ave 
V (i, ) Micountieriter™"-« seas si v. 
Ccoune(weite™) « read PE Dv 


when penleuete this reduces to: 
a. Icoumtwrnen) e ree = onto. e rast 
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This weakening term is tested in each of the' six events in valid orderings for which 
the preliminary condition is not satisfied. It is found-that the weakening term is satisfied in 
each case. Therefore, disjoining the weakening. tefm to the preliminary condition obtains 
the correct condition. The condition for gate write™™™* from: conjunct apdbz is: 

count(read”™™**).~ countivead™*") v 


[count(write*™") @ read'*?"*'] = [count(write™") @.read’wr"*], 


This condition makes sense incuvely 7 The frat dij states. that there are no 
unfulfilled requests for activations of "read". The second es that the most recent request 
event for “read” took place at a point 2 at which no activation of “write” was active. 
Therefore, a “read” activation is allowed to proceed ahead of the next waiting “write” 


activation if it was fecaiested during the previous “write” activation. 


There remains conjunct apdb, to analyze: 
(writer => read (Pt aed write, er) > 
3m (read ret > write a read*"'*")). 
Unfortunately, the analysis of this conjunet. is even more’ ‘complicated than that of the 
previous conjunct, owing to’ the: fact that there ‘aré 30 jpossitte orderings of the 5 events 
contained within it. These Rene ave listed in Figure 6:4. 
Rather than go ee the sven a the derivation, the complete pines will simply 
be summarized. Of the 30 onighings the sriterilige eee (1) through (23) are found to 
be valid. Orderings (24) through (30) are invalid, with the offending event in each being 


read;*"*". A condition must therefore be derived for gate read*™*". When the preliminary 
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Figure 6.4. Possible orderings for apdb, 


(1) read ‘ewes! => write" => write,*"*" => write," => read eee . 
(2) read,feqvest —> write,"ewe™" => write;*"*" => read "ier => write,,°"" 
(3) read feqest => write"ewes! => read *mer => write;*™*" => write,,°"" 
(4) read erst => reag enter —> write," => write,*"*" => write,.""" 
(5) read fewest —> writer! => write,,°"" = write?" = read antes 
(6) read ‘ewest —> write," => write,/ewest => write;°"'*" => read enter 
(7) read feawest => write, °*" = write;erest => read enter —> write;°"'*" 
(8) read,tewest —» write;“eue™ => write," => read "er => write,°"*" 
(9) read ,"ewest — read i => write, => write," => write?" 
(10) read ic => read Pal => write," => write,ewe"t = writen" 
(11) read ‘ewes! = write," => read*"*r => write,°est => write?" 
(12) read iaaee => write,ewest — read *mer = write," => write," 
(13) write," => read 7°! => read *"'" => write; => write,*"*" 
(14) write," => read fewest => writers! => read" => write" 
(15) write,,°"* => read ‘est => write," => write" => read on" 
(16) write," => write" => write" => read "owen! => read enter 
(17) write," => write," => write,°"*" = read /***! => read *"'e" 
(18) write," => write" => write,.°"" => read 7" => read °'" 
(19) write;"°wr* => writeo"'rr => read fewest => write,°% = read °™*" 
(20) writes! => write°"*" => read **" => read *" => write," 
(21) write,“ => read ,fowest —> write," = write,.°"" => read *nier 
(22) write, => read 7°"! => write," => write" => read "ie" 
(23) write;"°0st => read ‘ows! => write," => read ner = write" 
(24) write,"ewest => read jor! = read tr => write, °"" => write" 
(25) writes! => read ‘°o**t => read *"*" => write*"*" = write,.°"" 
(26) write “west ==> read [ere => write," => read enter —> write," 
(27) write out => write,.°"" => read owe! => writer => read enter 
(28) write," => write," => read /rnet => read °™*" => write" 
(29) write," => write," => read ‘rt => write" => read "ie" 
(30) write,"** => writer => read "wet = read °™e" => write,°""*" 


a ne a 


ome 


oa: 
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condition is formed, it reduces to FALSE. This is the extreme case of an eal strong 


condition, in that’ none ¢ of the 23 valid orderings is allowed. 


The ory event that precedes reaa,*" in all 30. orderings: is. read," The 
weakening term obutinedt by corisidering the state at event read," alone is: 
[count(write™™*) @ read" [count(write®™**) ® rea) 

This condition is-satisfted by. vatid orderings (i) through. (20), but not co) useee (23). 

This means that the characterizations of both the current state and the. previous State at 

- read,'***t must be:used at the same-time to obtain another eins term for these three 
orderings. The weakening term obtained is: : | . 

| [count{write™) e reaarevett esa 


which is satisfied 4 each of the orderings en through . _ 


The solution spicilicscion: ‘gondition for gate read" from. thia.coajunct is therefore 
the disjunction of the two weakening terms: | 
[count(write"*™**") e read'e**t] ‘“ [count(write™r Je read"ewest) v 


(fcounit(write""*)-e read") < count(write™™*)). 


Again this condition makes intuitive sense. ate first digjunet states that no activations 
of | “write” were requested but. waiting at the point. at which the. “pead”. ondgy, conekieration 
was requested. The'second says that some activation of “weite® has exited since the point at 


which this "read" was requested. One of these must be trie before the “read” c can enter. 
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The overall solution specification for specification apdb is given by the conjunction of 
the individual conditions obtained for each of the four conjuncts: 
For gate read*™*: 
(count(write*"*’) = count(write™")) A 
(([count(write’®™**') @ read’****!] = [count(write*™*’) e read"ewerty) v 
([count(write***) ¢.read'****] < count(write®***))) 
For gate write": 
(count(write*"*’) = count(write®)) a 
(count(read*™*") = count(read™*)) ~ 


((count(read"**™"') = count(read*"*’)) v 


([count(write*™*) e read'****'] = [count(write™*) @ read"****"))), 


The monitor implementation of this solution specification requires three variables wr, 
wn, and wx, to represent the current values of count(write™***), count(write*"*’), and 
count(write™), and three variables rr, rn, and rx, to represent the values of 
count(read"*™**), count(read*™*"), and count(read®"“). In addition, three variables are 
required to save values at a previous state: wrrr for [count(write’™™"') @ read'*?**], wnrr 
for Toount(write®"*") e@ read"°t**] and wxrr for [count(write"™”) e read"****"] The values 
of these variables are set in the monitor procedure Tead_request corresponding to gate 
read’*4*5! by saving the values of the variables representing the corresponding current 
quantities. For instance, variable wrrr, representing [count(write’?™"*) @ read"*?**'], saves 
the value of wr, which represents count(write"™""), The two conditian variables, and their 


associated predicates, are: 
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readentry: wn = wx A (writ = whit V wxrr<wx) 
writeentry: wn = wx A th =rk A (fr = rn V wher = wxrr) 


The monitor that is obtained appears in Figure 6.5. 
6.5 Disk head scheduler. 


The final example of this chapter is the “disk head scheduler” problem. Actually, the 
specification used here is a simplification of the actual disk head “scheduling specification 
that appears as Example 14 in Section 27. The reat disk head scheduler keeps the disk 
head sweeping in one direction untit all requesttd “accesses in that direction have been 
made, then reverses the direction and repeats. Accesses sire made as the requested tracks are 
_ encountered in the sweep, so’tHat the next track tobe accessed is the ‘One that is closest to 
the currently accessed track in the direction being swept. The simplification here involves 
disregarding ue direction else the disk head is sweeping, We simply wish that the 
next track to be accessed is closest to the currently accessed track of all requested, tracks in a 
| given direction. The requirement thatthe disk head sweep. continuously in.qne direction 
until further accesses — been requested in that direction is omitted. This allows the 
specication 19 be comiderably simplified Ghough, ala iniroders. the posibity of 


starvation, as noted in Chapter 7). 


We assume here that accessing @ disk thick is accomplizhed by means of an operation 
named “a* on the “disk” daté type. This’ operation’ takes a ‘single parameter x of type 
“track no”, giving’ the value of the track number being accessed. Activations of “a” must be 


mutually exclusive, since only one access can occur at a time. “The first conjunct of 
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Figure 6.5. Monitor for alternating priority database 


apdb = monitor; - 
wr, wn, WX, Ir, rn, rx: integer; 
wir, wnrr, wxir: integer; 
readentry, writeentry: condition; 


write_request = procedure; 
wr := wr +1; 
choose 
condition¢queue(readentry) A 
wn = wx A (wrrr = wnrr V_ wxtr < wx): 
condition$signaKreadentry), 
condition$queue(writeentry) A 
wn = wx A rerx A (rr=rn V ownrr = wxrr): 
condition$signaKwriteentry), 
end; 
. end write_request; 


write_enter = procedure, 
if wn # wx V m#rx Y (rr #m A wher # wxrr) 
then condition$wait(writeentry), end; 
wn := wn +I; 
choose 
condition$queue(readentry) A 
wn =< wx A (wrrr = wnrr V wxrr < wx): 
condition$signaKreadentry), 
condition$queue(writeentry) A 
wn=wx A rerx A (rr =m V wher = wxrr): 
condition$signaKwriteentry), 
end; 
end write_enter; 


write_exit = procedure, 
WX := wx + 1; 
choose 
conditiontqueue(readentry) A 
wn = wx A (weer = wner V_ wxrr < wx): 
condition$signaKreadentry), 
condition$queue(writeentry) A 
wn = wx A merx A (rr=m V worr = wxrr): 
condition$signaKwriteentry), 
end; : 
end write_exit; 


ay 


Sos, 
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read_request = procedure; 
rr := rr +i; 
WITT := WY; 
wr := wn; sng Tes a Gh ee 
WXITr := WX; : 
choose os 
condition$queue(readentry) A 
wn = wx A (wrrr = wnrr V -WET.< Mx) >: 
condition$signaKreadentry), 
condition$queue(writeentry) A : 
wn = wx A rn=tk: A-GT = ra: senance warrk 


condizion$signaXwriteentry): - 
end; eee ae Oe 
end read_request; ss lk, tnel is A 


read _enter = procedure 
if wn # wx Vv (wrrr * wnrr A wxrr 2 wx) 
then condition$wait(readentry), end; 
rm:=rn el]; 
choose 
condition$queue(readentry). A. 
wn = wx :/A. (Wrrk.» WATT V swxrr< wx): 
condition$signaKreadentry); 
condition$queue(writeentry) A 
wn = wx A rm=tk A(t re MV. nar «wxrr): 


condition$signaKwriteentry); 
end; SiGe ae eas 
end read_enter; ~ = 


read_exit = procedure; 
rx := rx +1; 
choose 
condition$queue(readentry) A 
_wnewx A (wrrr = worr Vo WXxEF <.wxk- 
condition$signaKreadentry), 
condition$queue(writeentry) A ee 
wnewx A mark. A (rereV ‘eet sowreeey 
_ condition§signaKwriteentry); 
end; eae 
end read_exit; 


“ae: wn, Wx, rr, rn, rx := 0,.0,0,0,0,0 . 


wrrr, wnrr, wxrr, := 0, 0, 0; 


end apdb; 
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specification dh specifies this mutual exclusion, and the second specifies the scheduling 
policy desired: - 


(ay => ay) > (ay => a) A 


((a,(x2yorr*t => ay (x1) => a(x2)Pr') vn | 
(aj(xayert => ay (xt)™* => a (xayener) A 
(xl < x2 <x3 V xl >x2>x3) 3 
(a,(x2)"" => a(xayen'e"). 
The analysis of the first conjunct has been carried out already in Section 63, where the 
"same property was specified for operation “write” as part of the “readers-writers’ property. 


Here we will consider the scheduling property conjunct dho. 


First, the argument constraint predicate (xl < x2 < x3 Vv xl > x2 > x3) must be 
incorporated into the conjunct. The predicate already appears in the hypothesis of an 
implication. It can be incorporated by parameterizing it and then qualifying the 
appropriate procedure activations. The parameterized sein of the predicate is 

(xl eu) A (x2=t) A (u<t<x3 V u>t>x3). 
This means that activation a,(xl) must be qualified with the predicate (x1 = u), activation 
a,{x2) with the predicate (x2 = t), and activation a (x3) with the predicate (u <t < x3 V u > 


t > x3). The transformed specification then becomes: 
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© Ea fx) | (x2 = TP => Lay (xt) | cl = uN fa lcd) | (x2 = YPM A 
(lax3) | (a <t < x3 Vu >t > x3)rerrmt => [ay (xl) | (xl = uy 
=> ite Mwct<x8.vurst> ayy os 
> (Laj(x2) | (x2 = YPM = [a(xd) [(u <t < x3 vu > b> x3) 


Now that the argument constraint information has beeti“iticorporated into the conjunct 
by means of qualification, the (aiidbpsla eae ptcbid formally. There are five events 
mentioned in the conjunct: Lbs 

_ Evexpldtig) = {fagix2) (x2 = 27°F, fa(e2) 44902 mt) IO), Ey (a (xd =u) 4, 
[a (x3) (ut < x3 V uot > xO falk3) 4 (a ctx 3 Wa ot > xappriery, 
There are 30 possible orderings among these-five events.:Ruther than list alt.30 of them, 
ly the two invalid ones are given mere: | 
a (x2) 1x2 : ore => ae Mu <te <x, Vue t> aye 
ayia I I (xl = one = [a 8) <t< x3 v Vu>t> axa» => 
a (e212 =o —_ 
(2) [aj(x3) I(u<tex3vust> aro = 62) x2 - oreo = 
Cay (xi) | (xl ar = apo 10 etex3VU we oe => 
fay(x2) | (2 a — | 
The offending e event in each is [a re) | (u die x3 Vu>t> >are ‘This means that a 


condition must be derived for gate [a(x) f Fe < t <x VU>t> rte, Since the state 


_. Characterization is the same at the point of the offending event in both orderings, this 


characterization becomes the term D;: 


3 Gi, k) (counttfalx) 14x = a)P™) 2k A 
count([a(x) |(u<t <x Vu >t> xp ey An couet(Dalx) | (x= 7") > in 
count(fa(x) | (u<t <x Vu >t >.9™).<3 ” counttiiitx} (x= "")) < i) 


Ene term D,, being the disjunction of of 23 characerzations is quite complicate. 
_ However, when the presi (Dy A : D mi is constructed, the formula can be anplited 
considerably. ane, result of the simpleton i is to arrive at the following preliminary 
condition: — wes | 
V i (count([a(x) | (x = ee) <i Vv count(la(x) | (x = t)}"")) 2 i). 
This is equivalent to the-even simpler ~ : 
count(la(x). | (x = Hye") eonnedin(x):| (2% PM): 
This condition is found to satisfy alt the valid orderings, and therefore is correct as it 
stands. 
The overall solution specification for specitication ai ‘consists of the following gate 
conditions: 
For gate a*™*: count(a®™") =.count(a"™) 
For gate. fa(x) |{u<t-<x Vu> tsa): 
count([a(x): | Gx = t) Fe") ».count(fa(x) f(x = Pr") 
where wis the parameter of the activation corresponding to 
the most recent a event. © =» 


A monitor must now be constructed to implement this solution specification. 
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The monitor must contain three procedures. a_yequest, a_enter, and a_exit, to 
correspond to the. three. event classes... Since’ there are: qualified. gates: in’ the salution 
7 specification, each of the monitor precedures must-take the same parameter x aS:aperation a. 
There must be variables an and ax to ds olueais count(a™"") and hice respectively: 
In addition, there must be a local variable i) wot ype tackn0, the the s same tpe as’ Lame t, 
representing the value of the parameter of the most recent all on procedure a_exit. This 


variable should be initialized to an aipropriale value, such | as s the minimum possible tr track 


number. 


In order to implement the parameterized counts, there:mwust be:-two objects atreq and 
atent of type counts[track. no] to halk: she -values ‘6f -countiladx): |.(x = ryewrst) and 
count([a(x) | (x =: £)}°"!°9: for. all. values of x. Procedure :a_request: dacrements acount én 
atreq, and procedure a_enter increments a count in atent. Each of these objects must. be 


created in the initialization code for the monitor. 


The qualifying predicate on the p™" gate 
(U<t<K. Viowrtsxy i 
is a non-functional relation. The entry cofiditions must be-implemented by an object aentry 
of type conditionsftrack_no}, that-holds tte: conditions for all:relevant values of x. A 
_ condition for: a given vatue of-x:is. added to aentry: by ats "add" operation at the start of 
procedure a_enter. The predicate scotintsa With: the tondition:for value t is given by 
an = ax7a cnts$gat(atceg; t) m tntstgetintent;4), 
combining the predicates associated with the unqualified and qualified gates. It is also 


necessary to have an object “tracks” of type set[track_no] to maintain the set of relevant 
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track numbers. Elements are added to track by “insert” operations within procedures 


a_request and a_enter. The resulting monitor appears in Figure 6.6. 


- [88 - 


Figure 64. Monitor for disk head scheduler 
dh = monitor; 


an, ax: integer; 

u: track_no; 

atreq, atent: counts{track_no}; 
aentry: conditions[track_no} 
tracks := set{track_no}, 


a_request = procedure(x:track_no), . 
counts[track_no]$incr(atreq, x); 
set{track_no}finsert(tracks, x), 
for z:track_no in conditions[track_no#domain(aentry) do 
if condition$queue(conditions{track_noMget(aentry, z)) then 
ok:boolean := true; 
for t:track_no in set[track_no}Selements(tracks) do 
if (u<ct<z Vu>rt>zZ) A 
, (an ax v countsltrack_no}¥get(atreq, t) * 
counts{track_no}Bget(atent, t)) 
then ok := false; end; 
end; 
if ok then condition§signaXconditions{track_nolget(aentry,. 2)); end; 
end; 
end; . 
end a_request; 


a_enter = procedure(x:track_no); 
conditions[track_no#add(pentry, x), 
for t:track_no in set[track_no#elements(tracks) do 
if condition¥queue(conditions{track_no}éget(aentry, x)) A 
(an * ax v counts{track_nolget(atreq, t) * counts{track_no}$get(atent, 0) 
then condition$wait(conditions{track_no}$get(conds, v)), end; 
end; 
an := an «1; 
counts[track_noJ$incr(atent, x); 
set(track_no}$insert(tracks, x); 
for z:track_no in conditions{track_no}¥domain(aentry) do 
if condition$queue(conditions{track_no}éget(aentry, z)) then 
ok:boolean := true; 
for t:track_no in set[track_no}elements(tracks) do 
ff (u<t<z Vurt>2) a 
(an * ax V counts{track_no}Sget(atreq, t) # 
counts[track_no}get(atent, t)) 
then ok := false; end; 
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end; 
if ok then condition$signa\(conditions[track_no}$get(aentry, z)); end; 
-end; 
end; 
end a_enter; 


a_exit = procedure(x:track_no); 
ax := ax +1; 
U := X; 
for z:track_no in conditions[track_no}¢domain(aentry) do 
if condition$queue(conditions{track_no}tget(aentry, z)) then 
ok:boolean := true; 
for t-track_no in set{track_no}#elements(tracks) do 
if (u<t<z Vurto2a 
(an # ax v counts[{track_no}tget(atreq, t) « 
counts(track_no}€get(atent, t)) 
then ok := false; end; 


end; 
if ok then condition$signaKconditions{track_nolget(aentry, z)); end; 
end; 
end, 
end a_exit, 


an, ax := 0, 0; 
u := track_no$min(); 
atreq := counts{track_no}fcreate(); 
atent := counts[track_nolfcreate(), 
aentry := conditions{track_no}€create(), 
tracks := set[track_nolécreate(); 

end dh; ; 


This empty page was substituted for a 
blank page in the original document. 
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Chapter 7 


Detecting Erroneous Specifications 


7.1 Introduction 


The flexibility of the problem specification language makes it possible to specify a 
wide variety of synchronization constraints. Unfortunately, this flexibility also permits 
erroneous specifications to be constructed. Certain kinds of errors in specifications can be 
detected in attempting to derive equivalent solution specifications. As noted in Chapter 4, if 
a specification constrains when in a history, say, a request event can occur, this results in an 
invalid ordering being found in the derivation algorithm for which the offending event is 
of type request. Since this is erroneous, in that the underlying model requires events other 
than enter events to be unconditional, the derivation algorithm detects this error and fails 


to construct an equivalent solution specification. . 


There are other kinds of erroneous specifications, however, for which equivalent 
solution specifications can be derived. These specifications are compatible with the 
underlying model, but the synchronization constraints they specify display certain forms of 
undesirable behavior. Two such forms of behavior are the potential for deadlock and 
starvation. Deadlock results from a situation being overconstrained, so that each of a set of 
waiting processes is prevented from proceeding by the siresents of all the rest. Starvation 
means that the constraint that is specified may be too rigid, in that certain processes are 


prevented from proceeding indefinitely. 
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A problem specification that manifests ‘one of these forms of behavior results in the 
derivation of a solution. specification: that does likewise, -Mowgyer: the:forin of the solution 
specification makes the analysis required to detect these erroneous behaviors much more 
tractable than for the problem specification itself. This chapter presehis algorithms for 
performing such analysis. ‘They can pe used, once 4 solution specification has been derived 


from a problem specification, as a check on the soundness of the original specification. 


By the ee in Chapter 4 justifying the derivation ‘algorithm, the set of histories 
allowed by a derived solution specification is exactly equal to'the set allowed by the original 
problem spetification:': This’ meatis ttiat a potential for deadtock’ or ‘starvation cannot be 
introduced into the solution specification by the detivation itself, since if this were possible, 
then there would have ‘to’ be one or more histories’ valid with réspect to the problém | 


specification but not to the solution: specification. Rather,’ sinte the  stfution  spetification 


eee pee 


corresponds exactly to the problem specification in ic-termé,‘ahy potential for 


For example, a potential for deadlock would‘ be reflected by thie existerice in a valid 
history of request events for which’ the correspondiiip énter events could ‘never ‘satisfy the 
specification. Assume the existence of sucha history atid ee ‘validity with vesped’ to a 
solution specification. Ther this same history must bé valid with’ réspett to’ the problem 
. specification, and the entér events must fail to satisty the problent specification, as well Of — 

. course, the reverse is similarly true. Thus tfie solution spécifitation must coritain exactly the 
same potential for deadlock as the problem specification. In a sittilat way, starvation 


implies that there are valid histories in which the request and enter events for a particular 
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Operation activation are separated by an arbitrary nureber of. other. request-enter event. — 
pairs. For a problem specification and a, solution specification that are valid with respect to 


exactly the same set of histories, starvation in one.implies. starvation, in. the other. 


Since the solution specification is state-oriented, it ‘és a acaien form on ‘which to. 
perform the analysis for these properties. The solution specification ‘an be used to 

determine under what conditions, if any, deadlock ‘and starvation are possible. ‘Such _ 
possibility, though, arises due to the original problem specification, and it is there that a 


correction must be made. 


7.2 Deadlock detection 


In a survey paper ((Hol72).0n the subject, deadlock 4s. defined. as. "the situation. in... 


which one or more processes in a system are blacked forever. because of 1 ts. that 


can never be satisfied.” In the context of this thesis,.. deadlock arises when a problem 
specification overconstrains the order of events in certain situations so as to prevent any of 
a group of requested accesses from ever occurring. “The ey comics in the derived 
solution specification form a basis for characterizing possible deadlock situations in terms of 
the synchronization state of the object. “Tf deadlock is impossible, then. each such 


“3 acim. 2Tse | 
characterization can be proved to lead to a contradiction. 


The problem of deadlock detection has been, studied fairly extensively, particularly for 
operating systems (eg. (UHav68}, [Hab69]) and database systems ((Cha74). The bulk of this, 
work has used a common scenario for deadlock: Each process in a collection of concurrently 


executing processes holds exclusive access to one or more scarce resources, and is blocked 
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because of a request for resources held by other processes in the collection, The scarce 
_ resources are commonly viewed as devices in the tase of operating systems, and locks in 
database systems. Unfortunately, shared abstract data ‘objects: are’ not really similar to” 
peripheral devices, which are serially reusable and must be “owned” by one process at a 
time. Nor is the database paradigm of setting and ecu locks on parts of the database 
very applicable i most Situations involving data Me sie a ie Blocking of processes 
competing for access to an abstract data object more often results, from calls on particular 


operations of the abstraction, rather than the iscanpiieaans of the data object they access. 


Closer to the mark, from this point of view, is the work by Holt ([Hol7I], [Rob75)). 
Using a Petri net-based model, Holt is a system as a set of states with transitions 
beech them. With this approach, a process is “blocked” in’'a state’ when’ there is no 
transition it cafi make to-another state. Deadlock’ results from a process being blocked in all 


reachable states of the system. The approach to be desttibed in this section is similar. 


. The solution specification into which the Specification is transformed i is a convenient 
form on which to 0 perform deadlock bcsee) faa The control points at which processes can be 
blocked are the enter gates, and the conditions the processes are awaiting to become 
unblocked are the corresponding entry conditions. A deadiock corresponds to one or more 
processes waiting at each of one or more gates, on conditions that can never become true. 
(It is assuthed throughout that ali operation activations terminate, so that processes can 


deadlock only via the synchronization ‘code itself.) 
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For example, consider a data abstraction with two operations p and q. Suppose that 
in deriving the solution specification from the problem specification, it is discovered that a 


enter 


condition for passing through the p*"”’ gate is 


count(q’****) = count(q*"*’). 


enter 


Now suppose also that a condition for the q*"'™ gate is 


count(p'e**"") = count(p*™*’). 


enter and 


Obviously then, whenever there is a process waiting at each of the two gates p 
q°"'*", these two processes are deadlocked. Each prevents the other from proceeding and 
thereby enabling the condition that it itself is awaiting. This means that the original 


problem specification is in error, in that the constraint it expresses prevents either activation 


in the given situation from ever proceeding. 


In the general case, a necessary but not sufficient condition for a collection of processes 
_ to deadlock over access to a shared data object is for each of these processes to be waiting at 
an enter gate for a condition to be satisfied. Whether or not this situation is a potential 
deadlock depends on whether the conditions on which the processes are waiting can be 
enabled by subsequent events associated with the shared object caused by other active 
processes. The idea behind the deadlock analysis technique to be described here is to 
characterize the synchronization state of the object at a potential deadlock point, a point at 
which processes are waiting at enter gates. This characterization then contains sufficient 
information for determining whether the entry conditions can be enabled by other active 
processes, or whether the waiting processes themselves prevent the conditions from ever 


becoming satisfied, in which case the situation represents a deadlock. 
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‘Each potential deadiock situation is distinguished by the subset of enter gates in the 
system at which onecer more processes are waiting. The terminology used ‘here is that an 
operation is blocked if there are processes waiting at the asiociated enter gate to execute it. 
If there are n operations defined rian abstract data type, then there are (2" - 1) potential 
deadlock situations, since any subset of the operations may be blocked, except the empty 
subset. An empty set of blocked ‘operations could not, of course, represent a deadlock 


situation. 


A complication arises from the use of qualified gates in solution specifications. When 
there are two or more enter gates for a particular operation, with a different qualifying 
predicate on each, the easiest point of view to take is that they behave Jike gates controlling 
completely different operations. In the context of deadlock analysis, it is simplest to consider 
two qualifications of an operation p, [plv) | Qy(v)} and {ptv) 1 Qolvy, as if they were 
separate operations p and po, since each distinct qualification of p can independently be 
blocked, just as different operations can. The catch is that the qualifying predicates Q, and 
Qo may not be independent, and if, for example, Q> Qo, then whenever [p(v) 1 Q(v)1 is 
blocked, [p(v) | Qo(v)] must be as well. In general, however, it is not always possible to 
determine when one qualified class is a subset of another. Always treating different 
qualifications of an operation as separate operations is a coniervative approach which is 
guaranteed not to overlook any potential case of ‘deadlock. Throughout this chapter, 
therefore, when reference is made to a data abstraction having n operations, the reader 
should understand that the intention is for different qualifications of an actual operation to 


be treated as separate operations. 
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It is straightforward to characterize a situation in which an operation is blocked. If 


enter 


C(p) is the condition for gate p*™*’, then the condition of operation p being blocked is 
expressed by the formula B(p): 
(= C(p)) A count(p’®***!) > count(p*™*’) A count(p*"*’) = count(p*"). 


That is, when p is blocked, there are no active executions of p, but one or more activations 


have been requested and are waiting because the entry condition C(p) is not satisfied. 


Assume that the potential deadlock situations are numbered I, 2, ... , (2" - 1), and let W, 
be the set of blocked operations in situation i. Formula U;, will denote the characterization 
of the synchronization state of an object in situation i, by expressing the fact that all 
operations in W; are blocked. . 

U; = A(Bip) |p € W)). 
If Uj; is equivalent to FALSE, then there is a contradiction in the information in the 
formula. This means that the potential deadlock situation is impossible, and that a 
condition on which an activation of one of the blocked operations is waiting ‘must be 
satisfied. If Uj is not equivalent to FALSE, then it represents a aracterieation of the 


circumstances under which the situation can occur. 


For a potential deadlock situation that is possible, the formula U; can be used to 
determine whether or not the situation in fact represents an actual deadlock. This 
determination can be made by checking whether any of the conditions on which blocked 
operations are waiting involve operations that are not blocked in the given situation. If 
not, then the conditions can never become satisfied, and the situation in fact does represent 


a deadlock. If one or more conditions involve non-blocked operations, however, then there 


oh Sb gl auibe BACARRA Fs oo, gia AEE 
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is not a deadlock, since a subsequent event involving one of these operations can “unblock” 
the situation and enable one of the waiting processes. At the very worst, such an event may: 
. change the situation to a different piendind deadlock situation; to be analyzed: separately. 
Therefore, it is sufficient to firid a single non-blocked operation: that ‘is invelved in the 


waiting conditions to disprove deadtock- for a given situation: 


As an Scariile of deadibock analysis, consider the solution specification for a writers’ 
. priority database given in Section 6.3. Since there aré two: operations, “read” and “write”, 
there are three potential deadtock situations--provesses waiting: only at the read*'*" gate, 
only at the write*"'* gate, and at both gates. In the-first situation, Wil) = { read}. The 
description of this situation U is given by the “blocked” condition on the “read” operation, 
B(read): 

(count(write™*"") = count(write™™*) v count(write"™™) « coant(write™™)) A 


count(read’*™**") > count(read*™**) A count(read®™*”) = count(read*"). 


The condition on which “read” activations are waiting involves events associated with 
the non-blocked operation “write” This ene an actual deadlock preenne since the “read” 
activations themselves are not causing the blocking. This ides - dees mean that 
the processes blocked at the read" gate will eventuatly proceed: There may-exist histories 
in which these processes are blocked forever, i.e. they may face the possibility of starvation 
(see the next section): What the analysis here shows:is ‘that circumstances exist, Involving 
possible future events associated with operation “write”, that make: unblocking of these 
processes possible. Their being blocked néed not be a permanent condition for all possible 


histories. 


The second situation is when only “write”: is: blotked, ie. W(2) = { write }.. The 
description here is Up = B(write): , 
(count(read*™*’) # count(read®*) v_ count(write™™") « count(write™")) A 
* count(write’e***) > count(write™*") A: .comatwrite™) = count(write™”), 
which can be simplified to 
: count(read*™™") #.couint(read®™*) nv 
count(write"****") > count(write*™") a count(write™") = count(write™™"),. 
Since the blocking condition invoives the neon-biocked operation “read”, this is also not an 


actual deadlock. 


The third potential deadlock situation for the abstract t object velvet waiting readers 


- and writers, so that W(3) = { read, write eh ‘This situation is 5 characterised by U3 = (B(write) 


A B(read)): 

(count(read™*") # count(read®"*) v count(wrie™) “ count(write arty) A 
count(write”*™™*t) > -count(writer™") A count(writer™") = conntoret™®. A 
(count(write™™*) * count(write"™") v count(write™) = count(write™)) A 
count(read"*"™"") » count(read"™""}'0 count(read™) «:connt(read*™). 

Here there is a contradiction, between the first disjunctive clause on the one hand, sv the 


third and. last eonjuncts on. the other. This. reduces the formula: to FALSE, proving the 


"situation to be impossible. Since this disposes Of ail. three- potential’ deadiock: situations, 


deadlock is proved to be impossible for this abstraction. 
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As a second example, consider the: bounded -buffer: example analyzed: in Section 6.2. 
Once again, there are two operations, and therefore three petential deadlock situations for 
this abstraction. The first is: when-only operation “Yem">is ‘blocked, so that Wi(i)-= { rem }. 
This is described. by the formuts- Uy =: Bérem): ike ne Cee veo 2 a ee a 
(count(dep**") < count(rem*"*) v_ count(rem**’) « cownetrern®™)) :n 
count(rem"*™**) >-countirem*!) A countirem*™) = count(rem®"), 
"which reduces slightly to. = 
- . wountidep"") s commt(rem?™™): no 
count(rem’e***!) 5 count(rem*™*") A count(rem*™*) « count(rem™; 
Since the formula is not Secret to ae al shuation, fs es ceneias oe the 


Peed 


condition « on 1 which * rem” activations are wating namely 


ae garb. hs 


count(dep™) < < count(rem*™"), 


epi 


involves sores ed nat is Rot piensa ” the situation. The means ptpat tthe condition 
bas y DO Qeeigiress 2 


need not be prevented from ever being satisted, and | so Pies does not ‘Fepresent an actual 


deadlock. 


The second situation. is when: only: "dep Is: blocked; and W(2) = °{:dep }. The 
characterization of this situation is given-by Us = Bidepy 
-(eount(rens”"4) < countidep***).--W--v: coluntidep™") eeountdep™) 0 ~ 


which simplifies to: 
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count(rem®*") < count(dep*""*") -NA 
count(dep'"**t) 5 count(dep*™*") A count(dep*"**") = count(dep*"*). 
This formula also is satisfiable, but once again, the waiting condition involves a 
non-blocked Operation, in this case "rem". This means that the potential for deadlock is 


averted. 


The third inactive situation involves both “dep” and “rem” being blocked.: W3 = { 
dep, rem }, and Uz = (B(rem) A B(dep)): 

(count(dep***) < count(rem®™*") v_ count(rem*"*) « count(rem®"*)) a 
count(rem™®***) 5 count(rem*™*') A count(rem*™*) = count(rem™") A 
(count(rem***) < count(dep*™**") -Nv count(dep*"*’) # count(dep**)) A 
count(dep'*?**t) > count(dep*™*") A count(dep*™*’) = count(dep*"*). 

For any value of N > I, this formula reduces to FALSE, since it implies that | 
count(dep*"*”) = count(dep™*) < count(rem*™™) = 
| count(rem™*) < count(dep*™*) - N. 
Therefore, the situation is impossible. In conjunction with the previous analysis of the 


other two situations, this means that no deadlock is possible for the “buffer” type. 
7.3 Starvation detection _ 


A related problem to deadlock is the notion of starvation. Starvation means that while 
a process that is waiting to access an object is not necessarily blocked permanently, a pattern 
of accesses exists that prevents the process indefinitely from proceeding. The opposite of 


Starvation is fairness, which indicates that every process is guaranteed eventually to have its 
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request for access fulfilled. A method analogous to that used for deadlocks can indicate a 
large class. of possible starvation situations, specifically those that are independent of 


parameter values. 


Unfortunately, not all starvation possibilities can be easily detected. For example, the 
disk head scheduler example of Example 14 in Section 2.7 is starvation-free, but the 
Simplified version analyzed in Section 65 is not. The fairness of the former specification 
depends upon (I) the range of track numbers being bounded, and (2) the set of track 
numbers being well-ordered. The proof that these are sufficient conditions for fairness 
involves non-trivial properties of well-ordered sets. In general, properties related to 
activation parameters, specifically to predicates qualifying gates in the solution specification, 
involve analysis that is too complex for the relatively simple starvation detection method 
outlined here. Such properties do not cause similar problems for deadlock analysis, since 
there the issue is simply whether any activations of an operation can proceed under any 
circumstances. Starvation analysis must determine whether an arbitrary activation 
eventually can proceed under all circumstances. This means that interactions among 
different activations of an operation become more important. For those starvation 
possibilities that can be detected by the method to be presented, the same approach to 
qualified gates is taken as for deadlocks. Different qualifications of an operation are treated 


as distinct operations, and each is analyzed independently for starvation. 
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‘The motivation for the starvation analysis presented below is as follows: For a process 
to starve, it must be kept waiting indefinitely at the enter gate for some operation. Since 
the synchronization mechanism itself is fair in scheduling activations whose entry conditions 
are satisfied, this can only happen if the condition on which the process is waiting is never 
allowed to be satisfied, due to the presence of other operation activations. (As before, all 
operation activations are assumed to terminate.) Therefore, it must be possible for processes 
executing other operations of the data abstraction to overtake the waiting process. 
“Overtaking” refers to the fact that even though the given process is waiting at an enter 
gate, processes making other activations whose request events occur later proceed through 


their respective enter gates ahead of it. 


If operation q cannot overtake operation p, then whenever an activation of p is 
blocked, eventually all activations of q that were requested prior to the request for p must be 
completed. Under circumstances in which the activation of p starves, therefore, no 
subsequent activation of q can proceed either. Thus the first step in the starvation analysis 
for a particular operation is to determine which other operations of the abstract data type 
can and cannot overtake it. The characterization of a starvation situation then sis that 
the given operation is blocked, and that no “non-overtaking” operations are carrelitty active. 
This characterization reduces to FALSE if there is a contradiction in the situation, meaning 


that starvation is impossible. 
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. poral the method of ae for each oeeatien p is the folowing ‘As before, nee 
denotes that p is blocked: 
Gb C(p)) a - count(p'*™**) > countipr) A oti = countip) 
For all q # PB construct the formula Tq, p) given by a 


Bip) A Clq) A tcountiqne) > outer 

This formula indicates ‘under what circumstances a process executing ‘operation q can 
overtake the process blocked at gate prnter, ie. when there are requested activations of q and 
the entry éonditien for q is ‘satisfied. It Tq P) is other than false, thers it is possible for oa 
activation of q to overtake the waiting activation of p. “Therefore nothing can be assumed 
about operation q in a starvation situation for p. If Tq, p) reduces to FALSE, however, 

then this overtaking cannot occur, and a process. waiting at po” will cause a_ process 
| subsequently arriving at q**" to be blocked as. walle: This. means that no activations of q 
can be active-in a starvation situation for. p. ‘Te Gna valentine sin Sip dx constinicied by 
Seteidlng to Bfp) the formula 

count(q?"""") « = count(q’™") 
fer each q for. which T(q, p) is FALSE. ‘That is, 
. Sip) = A (countiq?"'*’) = count(q’"") | Tq, p).= FALSE) 4 Bip). 

This indicates that since q.cannot_overtake p, eventually. no executions of.q will be active. 
If S(p) is FALSE, then starvation of processes attempting to execute p is.impossible, in that 
the hypothesized starvation situation for p contains a contradiction. Otherwise, S(p) 


characterizes a possible starvation situation. 
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Again, consider the writers’ priority database as an example. The condition for gate 
write®™*" js 
(count(read®™*’) = count(read™") A count(write*™*’) = count(write*”")), 

so the blocked condition for operation “write” is B(write): 

(count(read®™*’) « count(read®"*) v count(write®™*") = count(write™")) ” 

count(write’®™**) > count(write"™*’) A count(write*™*’) = count(write**), 
The condition C(read) is given by 

count(write’’™**!) = count(write"™*’) ~ count(write*™) = count(write®*"). 
This makes the overtaking condition T(read, write): 

(count(read®*™*') # count(read*"*) v_ count(write*™*) # count(write™™*)) ” 
count(write’**') > count(write™™™) ” count(write™™”) = count(write"™) a 
count(write™*?**) = count(write®™*") ~ count(write*™*) = count(write™™*) ~ 

count(read'****!) > count(read*™*"). 
Since the second and fourth clauses contradict each other, the formula reduces to FALSE. 
This means that the clause 
count(read®"'*") = count(read*"*) 
is conjoined to B(write) to form S(write), the starvation condition for operation "write": 

(count(read®"*") # count(read™*) v count(write*™*’) « count(write"™*)) A 

count(write’**) > count(write™*’) ~ count(write**’) = count(write™™*) a 
| count(read*™*) = count(read®”"), 
This formula in turn is FALSE, since the last two conjuncts together contradict the first 


disjunctive clause. Starvation of writers is therefore impossible. 
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-If a similar analysis is performed for the "Yeati” operation; Béread) is constructed as: 
(count(write’***') « count(write*™*”) v count(write’™*) = count(write™")) A 
count(read’**™) 5 count(read®*™") A couni(read®™*) = count(read™*). 
The condition of “write” overtaking "read", T(write, read), is then formed: , 
(count(write™™*) x count(write™*) -v count(write™™™)-« count(write™*)). A 
count(read“**"} > count(rexd*"™") ~ counttread™"7's count(read™*) A 
count(read*™™")ecount(read®™4) A count(write™™”) < count(write™™) a 
count(write™*") > count(write*™). 
This formula is not identically FALSE, however; ‘so that operation “write” can indeed 
overtake “read”. This means that the starvation“ condition S{read) is simply equal: to the 
"blocked condition B(read):. Since S(ready'is-Aot FALSE, starvation of readers is indeed a 
possibility, as expected, and can take place under the cifcumstavites given by: 
(count(write’°?***) * count(write'™*") -v -count( write") = count(write™")) A 
count(read”*"™"y > count(read*™"): 4°: Geunt(read™") & count(read*"*), . 
That is, as long as there are activations of “write” that are either requested and pending,-or 


active, then requested activations of “read” may starve. 


~ “8 
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Chapter 8. 


Summary and Evaliiition — 


8.1 Summary of the thesis 


This thesis has explored one approach. ta.the problem of. specifying synchronization - 
properties and synthesizing source language code to implement. them. The. approach taken — 


has depended on a basic model of abstract data. objects and..synchronization, which. was. / 
described in Chapter.2. The principal features of this model are. 
() Every data object is strongly typed, and any access of the object must be via a 
basic operation of the type of the abject, | 
_ (2) Certain points in_ time, called. events, are, distinguished in a computation : 
__ history, involving accesses,.of. a given data objec. -In particular, there are . 
three types of event: Fequest events,. which denote processes making. known 
their wish to gain access to the object; enter events, which. denote. successfully 
gaining access; and exit events, which denote relinquishing access. 


(3) The temporal precedence relation among events associated with a a ea data 


tye te: tidpeagn sey! - he a hite. WUE gob Pe cee Cre 


‘obied is a total ordering relation. 

“4 The furiction of synchronization i: is to constrain in certain mi ‘the time 
ordering relation on a data object, in particular the occurrence 2 of enter events 
within the total ordering. This function is ‘orthogonal to the meaning of the 

Operations by which processes access 5 the object, ‘and therefore c can and should | 


Pest 


~ be implemented Saas from those operations. . 


. ae 


- 0F- 


(5) Individual synchronization cOnstraines exist for each object in the system. 
Furthermore, a syn¢bronization constraint.is associated with a data type, and 


applies independently to each object of that type. 


Using this model as a basis, a specification heiagewas described in Chapter 2 for 
expressitig-synchronitation ‘properties’ of abstract’ data ‘types A néeation was devised for 
denoting events, «and: thé infix syitibol: "+9" "inthedueed for’ the:timé ‘ordering relation. 
Specificationis express coristtainty ‘Gn this felatfon Vit préditate tditultis formula’ involving 
the time ordering between universally quantified event ‘ekpréssions. “The quantification | 
causes the constraifit to apply to all events of a given cliss in a history. By explicitly stating 
the arguments to procedure invocations invelved in‘a ‘iiecification and using predicates to 
constrain these arguments; a eonstrainit’on the ‘=> elation cari’ be made to selectively apply 
to a ‘sub-class of evertts.” The format sematitiés of this ‘gpetifieation ‘Tahguage consisted of 
defining the validity of histories with respect to’ a ‘given "specification. A’ number of 


exdinptes of the usé’of the language to express synchronization Constraints appeared at the 


end of Chapter 2. ~ 


ie sarimlie saves language code implementing Aue specifigations, it was found to be 
desirable to use an intermediate form. | This form, called the solution _ Specification, was 
described in Chapter 3. It is an abstract representation of the solution to a specification that 
is procedural in nature but independent of the particular construct used for implementation. 
A solution specification consists of a collection of gates, which are abstract implementations 
of event classes. Synchronization constraints are implemented, by sttaching conditions on 


the synchronization State to gates for enter event classes. Processes are only allowed to pass 
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through gates when the corresponding conditions are satisfied. The semantics of a solution 
Specification, as of the problem specification, were defined in terms of the validity of 
histories. Translating a solution specification into an implementation using a 
synchronization construct such as a monitor is quite straightforward, as explained in 
Chapter 5. Therefore, the difficulty in synthesis is deriving the solution Specification from 


the problem specification. 


This derivation was the subject of Chapter 4. Besides simply identifying which gates 
are needed for a specification, this consists of constructing appropriate conditions on the 
synchronization state to associate with enter gates in order to implement the specified 
constraint. The construction of these conditions is accomplished by an algorithm that can 
be broken into several phases. First, constraints on the arguments to Lauvatond are 
incorporated into the rest of the specification by a technique called “qualification". Once 
this has been done, all possible orderings of relevant events are formed, and each ordering 
is identified as either valid or invalid with respect to the specification. The synchronization 
State at particular events in both valid and invalid orderings is characterized, and these 
characterizations are combined to form a preliminary condition. This condition is tested 
among the valid orderings; it either succeeds in satisfying them all and is therefore correct, 
or else it fails in one or more cases, and must be weakened by disjoining to it one or more 
other terms. These weakening terms are derived in much the same way as the preliminary 
condition, except that a smaller class of orderings is used, and the characterizations involve 


synchronization states saved at previous points in the orderings. 
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Chapter 6- presented sevéral examples ‘of’ ‘commorily “addressed ‘synchronization 
problems, which are specified and’ then synthesized by’ the approach Uescribed. These 
examples certaihty do not constitute a’ complete test of an approach, but they do represent a 
fairly broad range of the kinds of syricironizatiti properties’ found’ to bé of real interest. 
The topic ‘of Chapter 7 ‘was the’ analysis ‘Of a synchronization '‘tonstraint for possible 
deadlock and starvation. The solution. specification is a convenient form on Which to 
Periorey this sisal age aie were pee that for any given Specification can 
disprove we possibility of certain finds of hage-eaesth or r starvation, =~ aes the conditions 


under which they ¢ can take Pail. 


a LAP ER 


There are a number of ways of evaluating ne kara eat ag fe recht in 
Chapter 2. Tne example giana eut in sector cele attest to. vas ee to express a _wide 
range of synchronization phates The derivation 1 method discussed in (Chapter 4 and 
further illustrated by the examples of Chapter 6 semonsirates ‘ts suitability as an input 
danguage for the snes: algorithm. we oe related criteria are e especially. important, 
though subjective i in nature: gi constructbiity of the language, pow easy is it to write 


apectticalions, 0 and its comprehen how ay is it to uncersane specifications. 


Within. the framework of the model of synchronization tipori “which the language is 
based, the language itself is quite coftvenient’ for” wHtiny °synctironization “specifications. 
Since all of the standard logical operators of predicate calculus can be-used, and formulas of 


arbitrary complexity constructed, any constraint on time ordering can be expressed. These 
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specifications are relatively easy to write and to understand, since each logical operator has 
a natural interpretation. The extensibility of the language permits a complex specification 
involving many constraints to be expressed as a conjunction of individual clauses, each one 
specifying a single constraint. This feature, illustrated by the different versions of the 
readers-writers problem considered in Chapter 6, enhances both constructability and 


comprehensibility. 


There may exist grounds for criticizing the language based on disagreements with the 
underlying model. For example, consider the choice of which points in time to be 
designated as events. Each of the three event types request, enter, and exit has a uniform 
meaning, and each is necessary for expressing a wide class of synchronization properties. 
Properties concerning exclusion of operations involve enter and exit events, and scheduling 


properties use request and enter events. 


Disagreement may exist, however, over whether these three types constitute a sufficient 
set. In particular, assume that some operation p may be blocked from proceeding, not 
initially before the activation begins, but rather at some point in the middle of execution. 
That is, suppose p performs a certain amount of computation, then must wait for some 
synchronization condition to be satisfied, after which it completes execution with some 
further computation. There is no straightforward mechanism in the model (and therefore 
the language) for denoting this “intermediate” event. Such a situation must be handled by 
splitting operation p into two subsidiary operations pl and p2, which when executed serially 


constitute the whole of operation p. The intermediate point within p is represented by the 


exit event for pl and request event for p2. The condition on which it may be blocked is an 
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entry condition for gate p2*™". 


-, awhile this may not be considered an aesthetically satityng slution to the ppioeien:| . 
can Hs suited: The event types request, enter, and of were choren: in ear peaute they . 
possess a Uniform. interpretation independent. 2 the meaning ¢ of the particular operation. If 
a new event type intermediate were employed, its meaning (the intermediate point at which 
the operation may pause) necessarily woud be operation-dependent. Moreover, a single 
intermediate event ‘type would not be sufficient’ for ‘thanilling: operations’ that’ may be 
blocked at more than one intermediate point. For the sake of generality, theti, it would be: 
necessary to have an unbounded number of event types intermiediate-1, intermediate-2, 


~ eg *S4 


Whatever such an approach might gait’ in constrt 


lity of the tariguage would surely be” 
lost in reduced comprehensibility. The sollition cfidsen’ ‘instead’ ‘Of Sptitting the operation Pp 


into component segments pl, p2, etc. seems at least as satisfactory. °°” 


_ There’ is another important aspect of the spetification’ language used here. That is the 
ability to use synchronization specifications, along’ witti ‘the bodits' of the operations, to 
prove properties of ‘the data abstractions. One kind of proof is of the (Serial) correctness of | 
an operation, with the synchronization ‘specification used to show that all ‘possibly 
interfering operation activations are exclatied™*from concurrent “execution. The 
synchronization specification also can be used to demonstrate that céttain types of exception - 
handling are unnecessaty. An example is the bounded’ buffer specification analyzed in 
Section 6.2, by which it can be’ shown that an activation ‘of the “rem” operation ‘never 


_ Operates on an empty buffer. 
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One limitation of the specification language is an inability to refer to the state of the 
abstract data object to which a specification applies. There are good reasons for restricting 
the language in this way, as explained in Chapter 2. It is also true, at least theoretically, 
that any state information can be expressed -in,terms of events inthe history. However, 
capturing state information via histories can make the specification of certain properties 
rather awkward. For example, the disk head scheduling specification of Example 14 in 
Section 2.7 could be simplified significantly if reference could be made to whether the disk 
head is moving up or down (at the point at which a certain event occurs). This limitation, 
however, does serve the purpose of maintaining a clean separation between the 


synchronization aspect of the data abstraction and the actual operations. 
8.3 The synthesis method 


The method for synthesizing synchronization code from specifications was presented in 
Chapters 4 and 5. The justification of the Siescuieh for deriving a solution specification, 
and a discussion of cases for which it fails, is presented at the end of Chapter 4. Failures of 
the algorithm really reflect an inability of the relatively rigid solution specification. to 
capture certain synchronization properties of interest. For example, the algorithm fails on 
the first-come-first-served specification because this property cannot be implemented using a 
_ Separate queue for each operation of the abstraction. On the whole, though, and 
particularly with the use of qualified gates to capture parameter-related properties, the 


solution specification structure is able to express the solutions to almost all synchronization 


_ problems that can be specified in the problem specification language. 


wen ot Ta Nope creeper on em EE 
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The monitor imptementation of the -sokition specification is relatively straightforward 
inmost cases. The exceptian to this is the handling oF parameterized gates‘using:the types 
counts[T] and conditions[T¥] ‘The intplementation= of parameterized enter gates in 
particular, especially where the qualifying predicate is not a. functionaf relation; becomes 
quite. complicated. As noted i Chapter: 5, \a: certain-amount of simplification’ would be: 
possible if the user were to supply the range of valued Ghat cath parameter could assume. 
This information: could: aiso be used to prevent'the Gecreas# in expressive power that results 
os having ‘to make certain assdmptions about the solution specification. conditions in 


‘ a , 


order to construct a correct imptementation: 


Chapter 6 contains a small set oh. etaingh in wich Seasheasaieations are Cornmeal 
synthesized from problem specifications In fact, a considerably terger number of examples 
have hcald worked out, including a of ie oe a as Sones in | Section 
2.7, with the exception of hoe explicitly iG in Chapter 4 as failures. ihe mene 


end “hye jBG aared 


appears to » satisfactorily synthesize implementations for a a mice cae of Specifications, kere 


Plage RTS te tf EB HERE FL 


for hove EPropeaiies aed Ahuea sonition bs sagt anima ve obtained, as a noted above. 


Two other measures of the synthesis fethod are impartatit-to discuss here. “The first 
of these, the ‘practicality of the synthesis aigéritfim; eppearsopen to question. In the 
derivation of the solution specification, all’ possible orderings of: the event expressions 
contaitted in the specification must be considered; and since n events may have as mary as 
n! orderings, the atgorithm is necessarily expenential. In # less formal sense, the practicatity 
is weakened by the complexity: of ‘some ef the steps. of the ‘algorithm,’ particularly these 


requiring a logical simplification of formulas. Compensating somewhat is the fact that the 
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formulas involved are of a restricted form. Therefore, a smail collection of speciai-case 
simplifications, such as those appearing in Figure 4.2, rather than the power of a 
general-purpose logical simplifier, would probably be sufficient for implementing a system 
based on the method proposed here. Also, the ability to analyze each conjunct of the 


specification separately helps reduce the overall complexity. = 


Still, improvements in the algorithm are required to make it practical in, say, a 
compiler. The algorithm as it stands can be used manually by a person to implement a 
synchronization constraint expressed ‘in the specification language, or to informally check a 
hand-coded implementation. Further work, as discussed at the end of this chapter, is 


needed to automate the algorithm. 


With respect to the other measure of evaluation, the efficiency of the synthesized 
source code, the method can be judged to be quite respectable. There are certain 
inefficiencies that necessarily result from the use of a relatively fixed structure. Two aspects 
of the fixed structure here are particularly restrictive. One is the use of separate condition 
variables for different enter gates, which prevents the queuing of processes waiting to 
execute different operations on a common queue. The other is the derivation of a single 
entry condition applicable both initially when a process first attempts an access and 


subsequently when testing whether to allow the deferred access. 
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As a result, the synthesized monitor for the “alternating priority database” example of 
Section 6.4 is awkward compared to the rather elegant monitor coded by hand to solve the 
same problem in [Hoa74]. Much of this awkwardness, however, is due to the simple-minded 
implementation of testing for possible signalling all condition variables at the end of each 
monitor procedure. As indicated in Chapter 5, optimization of the signalling statements by 


eliminating provably unsatisfiable options is often possible. 


On the whole, synthesized implementations approach hand-coded ones in terms of 
efficiency for a large class of problems. The fact that all synchronization code manipulates 
only integer-valued quantities, and that entry conditions always consist of linear equalities or 
inequalities of such quantities, keeps the implementations efficient. The efficiency can be 
enhanced if other obvious optimizations are applied to the results of the straightforward 
synthesis, such as using a single variable for a quantity of the form 

count(ecl) - count(ec2), 


rather than two separate variables for the two different counts. 


Where the efficiency of the synthesized code becomes unacceptable is in cases 
involving parameterized gates, such as the disk head scheduler of Section 6.5. in order to 
accommodate the structure of the solution specification, the parameterized types counts[T] 
and conditions[T] must be employed to implement what amount to entire arrays of counts 
and conditions. Here, the fixed structure of the synthesized implementations becomes a real 
barrier to an efficient implementation, since "good" implementations of such properties make 
use of special mechanisms such as priority queues. With the exception of parameter-related 


properties, though, the performance penalties paid for most specifications seem to be within 
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the limits of what can be reasonably expected from an automatic synthesis system. 
8.4 Comparison with path expressions 


As noted in the introductory chapter, the work on path expressions ((Cam74], [Hab75], 
[Flo76]) most nearly matches this thesis in terms of overall goals. In evaluating the thesis, 
then, it is instructive to compare it with the path expression work to see to what extent each 
meets these shared goals. In terms of this comparison, the path expression language is 
restricted to its original description in [Cam74]. Later versions have added successively 
more features to the language, with questionable results. The original language simply 
contains the basic features that make path expressions analogous to regular expressions, 


» » and the repetition 


namely the sequencing operator “ ; “, the alternation operator 
operators “{ ... }" and “path ... end". The analogy with regular expressions embodies the 


basic philosophy underlying path expressions. 


The approach both of this thesis and of path expressions is to constrain the ordering 
relation on accesses to some shared abstract data object. Access of the abstract object is 
limited to a collection of basic operations associated with the type of the object, and so each 
language specifies a subset of possible object histories involving these operations to be 
_ valid. For path expressions, activations of the operations are treated as units, while this 
thesis has denoted three particular points in time associated with each activation as events, 


and dealt with these events rather than the activation itself. 
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The path’ expression approach’ is’ to. specify a global constraint for the complete 

sequence of accesses represented by the sbi eel a SP ueations of ahi thesis, on 
HaoE my e 

the other hand, represent local constraints for individual operation activations; because the 
activations invelved’ im ‘# Specification are quantlhed:ithe constraints ‘apply individually to 
each activation in the history. My intuition is tat Ident donsiraints‘aré Interentty simpler, 
both to construtt and te comprehend, and that people fivust translate global ‘constraints into 
locat ones to understand them. This is‘a subjective judgerient, however. 


ee re 


The path expresion language uses as s basic notion the ners al potas exctusion: 
sequencing, — concurrent sl ela Esced areata a higher te level Man snes more ae 
urea ordering + relation =. Use of such higher tye onere facilitates the expression 
of Properties tak ane based 7 os thee For ramps. he vender property, 
appearing as Pasitiate 3 in Section 2.7 in the he form a 

((write*"'" => write°"*") > (write, = writes) A 
(write? = read) -v = aie 
can be specified by the path expression — 
path { read}, write end. 


The gain in comprehensibitity anit constructability is obvious. 

However, t the same cou can be achieved d by al dh some sort hat macro facility vin me 
avivaage of this thesis. - For example, MUTEX@, qd could be c employed aa 1 shorthand 
abbreviation for the mutual exclusion specification of Example 2 in Section 27: 


(p;"" => qn") Vv qi" = pi"). 


and the readers-writers property then could be expressed as 
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MUTEX(write, read) A MUTEX(write, write). 
Such a macro facility would also be useful in identifying specifications for which 
implementations have already been derived in the past, thus eliminating replication of 


previous effort. 


The use of higher-level concepts as basic to the path expression language has the 
disadvantage that properties not closely related to these basic ones can be rather difficult to 
specify. For example, consider the writers’ priority database example analyzed in Section 
6.3. There the property was specified by adding to the readers-writers specification above 
the following conjunct, giving priority to operation “write” over “read”: 


(write,"ewe*t => read *"*") > (writer => read °™**). 


The‘path expression specification for the same example appears in [Cam74] as: 
path readattempt end 
path requestread, { requestwrite } end 
path { openread; read }, write end 
where 
readattempt = begin requestread end 
requestread = begin openread end 
requestwrite = begin write end 
READ = begin readattempt, read end 
WRITE = begin requestwrite end 
There is quite a lot of extra effort involved in adding the single property of priority to the 


readers-writers specification, and in terms of comprehensibility it leaves much to be desired. 
Even more discouraging is the fact that giving priority to “read” over “write” is done in a 
Slightly different manner. Little wonder, then, that in the next version of path expressions, 


appearing in [Hab75], priority becomes another pre-defined operator in the specification 
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language. 


The jstizilages of both this thesis and path expressions claim the virtue of 
extensibility, meaning ‘that further constraints simply “can | be added ‘onto previous. ones” 
without changing the existing specification. As the above example iNlustrates, this is not 
quite true of path expressions, since the addition. of the writers! priority property requires a 
change in the expression .of..the readers-writers: property .as well....In. this Shesis,. new. 


constraints can always be conjoined: to existing ones. 


The writers’ priority database example also illustrates the fact that with path 


expressions new operations sometimes must be Inyented fot the specification of desired 


properties. In this thesis, ‘this is also) true, but here it i is ; iimited ¢ to ‘the single nieecry of 


3 


breaking an operation into ‘serial ‘sections of code in between ‘which ‘the Process “executing 


WS PPR St 


the operation may be blocked, as explained in. Section 82,,.With path. expressions, blocking 
within operations must be handled in the sameway, th fact.” However, ie my also be 


necessary to construct a new operation whose ow. purpose is to ot an existing © ‘one, such as 


Bes da BS 7 


“requestwrite” in the example. Other exagaples..in..I both IGami4) and. {Hab75) contain 


numerous other such "hidden" operations used: sib glace ea urea coi a clean 


yeoss - 


separation of Si reoron sation code from the ‘data “abstraction ‘operations ‘themselves seems 


ve. ac Tg ae las Pa 


less. feasible with path expressions. ie 
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' The final comparison with respect to the specification languages themselves is that 
path expressions contain no facility for expressing properties that involve the parameters of 
operation activations. The only way to handle such properties would appear to be for the 
" Operation body to call different hidden procedures based on the satisfaction of different 
predicates by the parameters. Path expressions could then express synchronization 
constraints on these hidden procedures. There is no straightforward mechanism, however, 


as there is in the language of the thesis. 


The main thrust of the discussion in this section so far has been that the specification 
language of this thesis is superior, particularly in terms of criteria such as constructability 
and comprehensibility, to the path expression language. With respect to synthesis, however, 
there is no question that the path expression approach is better. A simple recursive 
algorithm in [Cam74] can automatically implement any constraint specified by path 


expressions in terms of semaphores and integer counters. 


In general, there is a tradeoff between expressive power of a specification language, 
and relative ne of synthesizing implementations from it. Because the path expression 
language is designed around a few built-in properties such as mutual exclusion, “canned” 
implementations of these properties can simplify the task of synthesis. The greater 
generality of the language of this thesis results in a far more difficult synthesis problem. It 
is interesting that in later versions of the path expression language ([Hab75], [Flo76)), 
additional features are added to increase the expressive power. These later papers do not 
include automatic implementation algorithms, and the problem of synthesis would appear 


far more difficult for these more complicated versions of the language. 


8:56 Future work: ~~" = + 


There area number of areas in which the work of this thesis could be extended in the 
future. Generally, the specification language sel sem sound as it stands, with the 
possible exception of oie inability to refer to the data sate of the resource, which is an issue 
that should be snvenivated: Further work i also needed on using specifications in proving 


properties of data abstractions. 


As noted in Chapter 5, information about: me range oF yaree of certain r pakaineten 
would be very helpful in constructing in implementations kes argument-reate properties: An 
automated escalis could interactively mont ad this information oon the user. However, it 
could also be Supplied as part of the orignal specification, al the specification fanguage were 


extended to handle it. : 


The synthesis method described’ here’ can’ only’ be: Viewed: ‘ts “a startitig point for 
Pursuing this general. Approach. Bi synthesis algoritnm i is very. complicated, ane: while 


' this is dictated to some extent by the generality of the specification language, the complexity 


almost certainly could be reduced, perhaps dramatically, by locking at alternative strategies. 


One area that could particularly ‘benefit from a different approach’ is ‘the use of 
qualified gates for argument-rélated  propérties” As ihificatéd “above: in’ Section 83, the 
implementations resutting from such cases afé uhaccéptably inefficient. It is unreasonable to 
have to perform a detailed search ih determining the’ state ‘variable 10 be ‘updated or the 


condition on which to wait. A change in the basit ‘solution ‘specification structure would 


probably be necessary to achieve acceptably éffitient' iiplerentations of arpurrent-related 
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properties. Unless some alternative were found, it might be better to eliminate 
argument-related predicates from the specification language entirely, even at the cost of 


reducing the power of the language. 


The use of information private to each process, as discussed in Section 4.7, represents 
one possible direction for extending the power of the solution specification. Private 
information would permit each process to look back in the history to a point whose state is 
important only to that process. This would increase the range of applicability of the 
derivation algorithm. Of course, adding this feature to the solution specification requires 
modification of the algorithm so that such information can be derived. This issue would 


_ have to be investigated. 


An alternative to private information would be a more flexible solution specification 
structure. As noted in Section 8.3, the ability to employ different queuing strategies and to 
have different entry conditions for a gate depending upon context would add expressive 
power to the solution specification. Again, the impact on the derivation algorithm would 


have to be considered. 


Another idea that might bear exploring is the use of more powerful data types than 
simple integers in both the solution specification structure and the source code 
implementation. Specifically, sequences of events may be a more natural concept by which 
to translate properties from history-theoretic to state-theoretic terms. One potential difficulty 
is the fact that there is no theory of sequences as rich as number theory, and no good 


analogue for sequences to the < relation on integers, which is so basic to the synthesis 
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algorithm. Also, the problem of source-level optimizations, which has. been addressed 


briefly in the thesis, would become much more serious. . 


A limitation of the work here that has been mentioned earlier is its dependence ona 
centralized synchronization mechanism for.each data abject. This, limits its applicability in 
Situations where, data objects. may be distributed.widely, around a system of geographically 
distant processors. It would be interesting to explore $0 what extent. this centralized-control 
bias is built into the underlying model, and see what problems. have ta be overcome in 


devising an implementation suitable for distributed systems. 


An interesting “problem growing out of the approach ‘here is whether or not 
synchronization constraints for an abstract data type can be derived ‘automatically from the 
implementation of the type. Obviously, questions such as whether one operation should 
have priority over another can only be decided by a person, sips there is no inherent 
Feazon to choose one priory scheme over another. However, the cde implementing the 
| operations of a type, possibly augmented by some internal Consistency requirement for the 
lower-level fepiesentation of objects of the type,'can provide enough information to 
determine many classes of synchronization constraints. Which operations must be mutually 
. exclusive of éach other can often be determined by analyzing the manipulation of shared 
variables used in the implementation of the type: A number of ‘techniques ‘employed in 
optimizing compilers can also be used: Heuristics such as dead code elimination and 
_ dependencies in the ordering of operations. Success in investigating this area could lead to 


the partial elimination of the need for synchronization code itself. 
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Of all the areas open for future work, however, the most obvious is the need to 
implement in an actual system a method such as the one described in this thesis. Many 
ideas look good on paper, only to founder when actually put into practice. A certain 
amount of system design has been done on paper, in order to help determine the feasibility 
of the system. Nothing has been actually run and tested, however, and only an actual 


implementation ultimately can be convincing. as to the feasibility of automatic synthesis of 


synchronization code. 


This empty page was substituted for a 
blank page in the original document. 
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